Build failure on FreeBSD 10 #1
Comments
|
Or not build on FreeBSD anymore :( Is this V8 head or are those problems with 5.8 in master? |
|
This is V8 head. |
|
Based on https://github.com/nodejs/node/blob/master/BUILDING.md, the minimum version of clang should be 3.4.2. I am not sure if it will necessarily fix the problem though, but as a starting point, let's try getting that updated on the FreeBSD machines? /cc @nodejs/platform-freebsd, @nodejs/build |
|
|
Closed
|
Closing in favor of nodejs/build#723 |
nodejs-ci
pushed a commit
that referenced
this issue
Oct 27, 2017
Currently when running the test without an internet connection there are two JavaScript test failures and one cctest. The cctest only fails on Mac as far as I know. (I've only tested using Mac and Linux thus far). This commit moves the two JavaScript tests to test/internet. The details for test_inspector_socket_server.cc: [ RUN ] InspectorSocketServerTest.FailsToBindToNodejsHost make[1]: *** [cctest] Segmentation fault: 11 make: *** [test] Error 2 lldb output: [ RUN ] InspectorSocketServerTest.FailsToBindToNodejsHost Process 63058 stopped * thread #1: tid = 0x7b175, 0x00007fff96d04384 * libsystem_info.dylib`_gai_simple + 87, queue = * 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, * address=0x0) frame #0: 0x00007fff96d04384 libsystem_info.dylib`_gai_simple + 87 libsystem_info.dylib`_gai_simple: -> 0x7fff96d04384 <+87>: movw (%rdx), %ax 0x7fff96d04387 <+90>: movw %ax, -0x2a(%rbp) 0x7fff96d0438b <+94>: movq %r13, -0x38(%rbp) 0x7fff96d0438f <+98>: movq 0x18(%rbp), %rcx (lldb) bt * thread #1: tid = 0x7b175, 0x00007fff96d04384 * libsystem_info.dylib`_gai_simple + 87, queue = * 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, * address=0x0) * frame #0: 0x00007fff96d04384 libsystem_info.dylib`_gai_simple + 87 frame #1: 0x00007fff96cfe98b libsystem_info.dylib`search_addrinfo + 179 frame #2: 0x00007fff96cfafef libsystem_info.dylib`si_addrinfo + 2255 frame #3: 0x00007fff96cfa67b libsystem_info.dylib`getaddrinfo + 179 frame #4: 0x00000001017d8888 cctest`uv__getaddrinfo_work(w=0x00007fff5fbfe210) + 72 at getaddrinfo.c:102 frame #5: 0x00000001017d880e cctest`uv_getaddrinfo(loop=0x000000010287cb80, req=0x00007fff5fbfe1c8, cb=0x0000000000000000, hostname="nodejs.org", service="0", hints=0x00007fff5fbfe268) + 734 at getaddrinfo.c:192 frame #6: 0x000000010171f781 cctest`node::inspector::InspectorSocketServer::Start(this=0x00007fff5fbfe658) + 801 at inspector_socket_server.cc:398 frame #7: 0x00000001016ed590 cctest`InspectorSocketServerTest_FailsToBindToNodejsHost_Test::TestBody(this=0x0000000105001fd0) + 288 at test_inspector_socket_server.cc:593 I'm not sure about the exact cause for this but when using a standalone c program to simulate this it seems like when the ai_flags `AI_NUMERICSERV` is set, which is done in inspector_socket_server.cc line 394, the servname (the port in the FailsToBindToNodejsHost test) is expected to be a numeric port string to avoid looking it up in /etc/services. When the port is 0 as is it was before this commit the segment fault occurs but not if it is non-zero. PR-URL: nodejs/node#16255 Reviewed-By: Anna Henningsen <[email protected]> Reviewed-By: James M Snell <[email protected]>
nodejs-ci
pushed a commit
that referenced
this issue
Dec 16, 2017
Remove a pointless adapter frame by fixing up the function's formal
parameter count. Before:
frame #0: 0x000033257ea446d5 onParserExecute(...)
frame #1: 0x000033257ea3b93f <adaptor>
frame #2: 0x000033257ea41959 <internal>
frame #3: 0x000033257e9840ff <entry>
After:
frame #0: 0x00000956287446d5 onParserExecute(...)
frame #1: 0x0000095628741959 <internal>
frame #2: 0x00000956286840ff <entry>
PR-URL: nodejs/node#17693
Reviewed-By: Anna Henningsen <[email protected]>
Reviewed-By: Colin Ihrig <[email protected]>
Reviewed-By: James M Snell <[email protected]>
Reviewed-By: Daniel Bevenius <[email protected]>
Reviewed-By: Khaidi Chu <[email protected]>
nodejs-ci
pushed a commit
that referenced
this issue
Oct 6, 2018
Reverting this enables us to provide slower, but longer-lasting
replacements for the deprecated APIs.
Original commit message:
Put back deleted V8_DEPRECATE_SOON methods
This partially reverts
https://chromium-review.googlesource.com/c/v8/v8/+/1177861,
which deleted many V8_DEPRECATE_SOON methods rather than moving them to
V8_DEPRECATED first. This puts them back and marks them V8_DEPRECATED.
Note V8_DEPRECATED that were deleted in the same CL stay deleted.
NOTRY=true
NOPRESUBMIT=true
NOTREECHECKS=true
Bug: v8:7786, v8:8240
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
Change-Id: I00330036d957f98dab403465b25e30d8382aac22
Reviewed-on: https://chromium-review.googlesource.com/1251422
Commit-Queue: Dan Elphick <[email protected]>
Reviewed-by: Yang Guo <[email protected]>
Reviewed-by: Michael Hablich <[email protected]>
Cr-Commit-Position: refs/branch-heads/7.0@{#49}
Cr-Branched-From: 6e2adae6f7f8e891cfd01f3280482b20590427a6-refs/heads/7.0.276@{#1}
Cr-Branched-From: bc08a8624cbbea7a2d30071472bc73ad9544eadf-refs/heads/master@{#55424}
Refs: v8/v8@9136dd8
Refs: nodejs/node#23122
PR-URL: nodejs/node#23158
Reviewed-By: Yang Guo <[email protected]>
Reviewed-By: Michaël Zasso <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
CI run: https://ci.nodejs.org/job/node-test-commit-freebsd/8853/nodes=freebsd10-64/console
We should probably upgrade clang.
The text was updated successfully, but these errors were encountered: