Skip to content
This repository

v0.6.0 Segmentation fault: 11 on OS X 10.7.2 via homebrew install #2061

Closed
gregferrell opened this Issue November 09, 2011 · 83 comments
Greg Ferrell

After doing an upgrade to node 0.6.0 on OS X, I get 'Segmentation fault: 11' when I attempt to do anything with the node executable aside from --version.

I completely uninstalled with a force remove for all version and reinstalled and still the same error. Have talked to other people with the same issue. (Node 0.4.x worked without issue for me via a brew install)

I've tried my best to Google the problem but my only two leads were someone on 0.5.9: http://stackoverflow.com/questions/7693237/node-js-segmentation-fault11

And someone that had a similar error with node 0.4.2, but was later fixed:
http://stackoverflow.com/questions/5210160/nodejs-0-4-2-segfault-on-start-fixed-in-v-0-4-5

Is there a better way to provide info on the issue?

Ben Noordhuis

Sanity check, do you get a segfault with master or the 0.6.0 tarball from http://nodejs.org/dist/v0.6.0/node-v0.6.0.tar.gz ?

ry
ry commented November 09, 2011

Please open it in gdb and provide a stacktrace

% gdb --args node something.js
(gdb) run
(gdb) backtrace
Greg Ferrell

Got lots of warnings on the intial before hitting run and backtrace so long list

$ gdb --args node simple.js

GNU gdb 6.3.50-20050815 (Apple version gdb-1705) (Fri Jul  1 10:50:06 UTC 2011)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "x86_64-apple-darwin"...Reading symbols for shared libraries ........... done

warning: Could not find object file "/private/tmp/homebrew-node-0.6.0-fM0b/node-v0.6.0/out/Release/src/node_main_5.o" - no debug information available for "node_main.cc".

warning: Could not find object file "/private/tmp/homebrew-node-0.6.0-fM0b/node-v0.6.0/out/Release/src/node_5.o" - no debug information available for "node.cc".

warning: Could not find object file "/private/tmp/homebrew-node-0.6.0-fM0b/node-v0.6.0/out/Release/src/node_buffer_5.o" - no debug information available for "node_buffer.cc".

warning: Could not find object file "/private/tmp/homebrew-node-0.6.0-fM0b/node-v0.6.0/out/Release/src/node_javascript_5.o" - no debug information available for "node_javascript.cc".

warning: Could not find object file "/private/tmp/homebrew-node-0.6.0-fM0b/node-v0.6.0/out/Release/src/node_extensions_5.o" - no debug information available for "node_extensions.cc".

warning: Could not find object file "/private/tmp/homebrew-node-0.6.0-fM0b/node-v0.6.0/out/Release/src/node_http_parser_5.o" - no debug information available for "node_http_parser.cc".

warning: Could not find object file "/private/tmp/homebrew-node-0.6.0-fM0b/node-v0.6.0/out/Release/src/node_constants_5.o" - no debug information available for "node_constants.cc".

warning: Could not find object file "/private/tmp/homebrew-node-0.6.0-fM0b/node-v0.6.0/out/Release/src/node_file_5.o" - no debug information available for "node_file.cc".

warning: Could not find object file "/private/tmp/homebrew-node-0.6.0-fM0b/node-v0.6.0/out/Release/src/node_script_5.o" - no debug information available for "node_script.cc".

warning: Could not find object file "/private/tmp/homebrew-node-0.6.0-fM0b/node-v0.6.0/out/Release/src/node_os_5.o" - no debug information available for "node_os.cc".

warning: Could not find object file "/private/tmp/homebrew-node-0.6.0-fM0b/node-v0.6.0/out/Release/src/node_dtrace_5.o" - no debug information available for "node_dtrace.cc".

warning: Could not find object file "/private/tmp/homebrew-node-0.6.0-fM0b/node-v0.6.0/out/Release/src/node_string_5.o" - no debug information available for "node_string.cc".

warning: Could not find object file "/private/tmp/homebrew-node-0.6.0-fM0b/node-v0.6.0/out/Release/src/node_zlib_5.o" - no debug information available for "node_zlib.cc".

warning: Could not find object file "/private/tmp/homebrew-node-0.6.0-fM0b/node-v0.6.0/out/Release/src/timer_wrap_5.o" - no debug information available for "timer_wrap.cc".

warning: Could not find object file "/private/tmp/homebrew-node-0.6.0-fM0b/node-v0.6.0/out/Release/src/handle_wrap_5.o" - no debug information available for "handle_wrap.cc".

warning: Could not find object file "/private/tmp/homebrew-node-0.6.0-fM0b/node-v0.6.0/out/Release/src/stream_wrap_5.o" - no debug information available for "stream_wrap.cc".

warning: Could not find object file "/private/tmp/homebrew-node-0.6.0-fM0b/node-v0.6.0/out/Release/src/tcp_wrap_5.o" - no debug information available for "tcp_wrap.cc".

warning: Could not find object file "/private/tmp/homebrew-node-0.6.0-fM0b/node-v0.6.0/out/Release/src/udp_wrap_5.o" - no debug information available for "udp_wrap.cc".

warning: Could not find object file "/private/tmp/homebrew-node-0.6.0-fM0b/node-v0.6.0/out/Release/src/pipe_wrap_5.o" - no debug information available for "pipe_wrap.cc".

warning: Could not find object file "/private/tmp/homebrew-node-0.6.0-fM0b/node-v0.6.0/out/Release/src/cares_wrap_5.o" - no debug information available for "cares_wrap.cc".

warning: Could not find object file "/private/tmp/homebrew-node-0.6.0-fM0b/node-v0.6.0/out/Release/src/tty_wrap_5.o" - no debug information available for "tty_wrap.cc".

warning: Could not find object file "/private/tmp/homebrew-node-0.6.0-fM0b/node-v0.6.0/out/Release/src/fs_event_wrap_5.o" - no debug information available for "fs_event_wrap.cc".

warning: Could not find object file "/private/tmp/homebrew-node-0.6.0-fM0b/node-v0.6.0/out/Release/src/process_wrap_5.o" - no debug information available for "process_wrap.cc".

warning: Could not find object file "/private/tmp/homebrew-node-0.6.0-fM0b/node-v0.6.0/out/Release/src/v8_typed_array_5.o" - no debug information available for "v8_typed_array.cc".

warning: Could not find object file "/private/tmp/homebrew-node-0.6.0-fM0b/node-v0.6.0/out/Release/src/node_signal_watcher_5.o" - no debug information available for "node_signal_watcher.cc".

warning: Could not find object file "/private/tmp/homebrew-node-0.6.0-fM0b/node-v0.6.0/out/Release/src/node_stat_watcher_5.o" - no debug information available for "node_stat_watcher.cc".

warning: Could not find object file "/private/tmp/homebrew-node-0.6.0-fM0b/node-v0.6.0/out/Release/src/node_io_watcher_5.o" - no debug information available for "node_io_watcher.cc".

warning: Could not find object file "/private/tmp/homebrew-node-0.6.0-fM0b/node-v0.6.0/out/Release/src/platform_darwin_5.o" - no debug information available for "platform_darwin.cc".

warning: Could not find object file "/private/tmp/homebrew-node-0.6.0-fM0b/node-v0.6.0/out/Release/src/node_crypto_5.o" - no debug information available for "node_crypto.cc".

warning: Could not find object file "/private/tmp/homebrew-node-0.6.0-fM0b/node-v0.6.0/out/Release/deps/http_parser/http_parser_3.o" - no debug information available for "http_parser.c".

warning: Could not find object file "/private/tmp/homebrew-node-0.6.0-fM0b/node-v0.6.0/out/Release/deps/uv/uv.a(core.o)" - no debug information available for "core.c".

warning: Could not find object file "/private/tmp/homebrew-node-0.6.0-fM0b/node-v0.6.0/out/Release/deps/uv/uv.a(dl.o)" - no debug information available for "dl.c".

warning: Could not find object file "/private/tmp/homebrew-node-0.6.0-fM0b/node-v0.6.0/out/Release/deps/uv/uv.a(fs.o)" - no debug information available for "fs.c".

warning: Could not find object file "/private/tmp/homebrew-node-0.6.0-fM0b/node-v0.6.0/out/Release/deps/uv/uv.a(cares.o)" - no debug information available for "cares.c".

warning: Could not find object file "/private/tmp/homebrew-node-0.6.0-fM0b/node-v0.6.0/out/Release/deps/uv/uv.a(udp.o)" - no debug information available for "udp.c".

warning: Could not find object file "/private/tmp/homebrew-node-0.6.0-fM0b/node-v0.6.0/out/Release/deps/uv/uv.a(error.o)" - no debug information available for "error.c".

warning: Could not find object file "/private/tmp/homebrew-node-0.6.0-fM0b/node-v0.6.0/out/Release/deps/uv/uv.a(process.o)" - no debug information available for "process.c".

warning: Could not find object file "/private/tmp/homebrew-node-0.6.0-fM0b/node-v0.6.0/out/Release/deps/uv/uv.a(tcp.o)" - no debug information available for "tcp.c".

warning: Could not find object file "/private/tmp/homebrew-node-0.6.0-fM0b/node-v0.6.0/out/Release/deps/uv/uv.a(pipe.o)" - no debug information available for "pipe.c".

warning: Could not find object file "/private/tmp/homebrew-node-0.6.0-fM0b/node-v0.6.0/out/Release/deps/uv/uv.a(tty.o)" - no debug information available for "tty.c".

warning: Could not find object file "/private/tmp/homebrew-node-0.6.0-fM0b/node-v0.6.0/out/Release/deps/uv/uv.a(stream.o)" - no debug information available for "stream.c".

warning: Could not find object file "/private/tmp/homebrew-node-0.6.0-fM0b/node-v0.6.0/out/Release/deps/uv/uv.a(darwin.o)" - no debug information available for "darwin.c".

warning: Could not find object file "/private/tmp/homebrew-node-0.6.0-fM0b/node-v0.6.0/out/Release/deps/uv/uv.a(kqueue.o)" - no debug information available for "kqueue.c".

warning: Could not find object file "/private/tmp/homebrew-node-0.6.0-fM0b/node-v0.6.0/out/Release/deps/uv/uv.a(uv-common.o)" - no debug information available for "uv-common.c".

warning: Could not find object file "/private/tmp/homebrew-node-0.6.0-fM0b/node-v0.6.0/out/Release/deps/uv/uv.a(uv-eio.o)" - no debug information available for "uv-eio.c".

warning: Could not find object file "/private/tmp/homebrew-node-0.6.0-fM0b/node-v0.6.0/out/Release/deps/uv/uv.a(ev.o)" - no debug information available for "ev.c".

warning: Could not find object file "/private/tmp/homebrew-node-0.6.0-fM0b/node-v0.6.0/out/Release/deps/uv/uv.a(eio.o)" - no debug information available for "eio.c".

warning: Could not find object file "/private/tmp/homebrew-node-0.6.0-fM0b/node-v0.6.0/out/Release/deps/uv/uv.a(ares__close_sockets.o)" - no debug information available for "ares__close_sockets.c".

warning: Could not find object file "/private/tmp/homebrew-node-0.6.0-fM0b/node-v0.6.0/out/Release/deps/uv/uv.a(ares__get_hostent.o)" - no debug information available for "ares__get_hostent.c".

warning: Could not find object file "/private/tmp/homebrew-node-0.6.0-fM0b/node-v0.6.0/out/Release/deps/uv/uv.a(ares__read_line.o)" - no debug information available for "ares__read_line.c".

warning: Could not find object file "/private/tmp/homebrew-node-0.6.0-fM0b/node-v0.6.0/out/Release/deps/uv/uv.a(ares__timeval.o)" - no debug information available for "ares__timeval.c".

warning: Could not find object file "/private/tmp/homebrew-node-0.6.0-fM0b/node-v0.6.0/out/Release/deps/uv/uv.a(ares_data.o)" - no debug information available for "ares_data.c".

warning: Could not find object file "/private/tmp/homebrew-node-0.6.0-fM0b/node-v0.6.0/out/Release/deps/uv/uv.a(ares_destroy.o)" - no debug information available for "ares_destroy.c".

warning: Could not find object file "/private/tmp/homebrew-node-0.6.0-fM0b/node-v0.6.0/out/Release/deps/uv/uv.a(ares_expand_name.o)" - no debug information available for "ares_expand_name.c".

warning: Could not find object file "/private/tmp/homebrew-node-0.6.0-fM0b/node-v0.6.0/out/Release/deps/uv/uv.a(ares_free_hostent.o)" - no debug information available for "ares_free_hostent.c".

warning: Could not find object file "/private/tmp/homebrew-node-0.6.0-fM0b/node-v0.6.0/out/Release/deps/uv/uv.a(ares_free_string.o)" - no debug information available for "ares_free_string.c".

warning: Could not find object file "/private/tmp/homebrew-node-0.6.0-fM0b/node-v0.6.0/out/Release/deps/uv/uv.a(ares_gethostbyaddr.o)" - no debug information available for "ares_gethostbyaddr.c".

warning: Could not find object file "/private/tmp/homebrew-node-0.6.0-fM0b/node-v0.6.0/out/Release/deps/uv/uv.a(ares_gethostbyname.o)" - no debug information available for "ares_gethostbyname.c".

warning: Could not find object file "/private/tmp/homebrew-node-0.6.0-fM0b/node-v0.6.0/out/Release/deps/uv/uv.a(ares_init.o)" - no debug information available for "ares_init.c".

warning: Could not find object file "/private/tmp/homebrew-node-0.6.0-fM0b/node-v0.6.0/out/Release/deps/uv/uv.a(ares_library_init.o)" - no debug information available for "ares_library_init.c".

warning: Could not find object file "/private/tmp/homebrew-node-0.6.0-fM0b/node-v0.6.0/out/Release/deps/uv/uv.a(ares_llist.o)" - no debug information available for "ares_llist.c".

warning: Could not find object file "/private/tmp/homebrew-node-0.6.0-fM0b/node-v0.6.0/out/Release/deps/uv/uv.a(ares_mkquery.o)" - no debug information available for "ares_mkquery.c".

warning: Could not find object file "/private/tmp/homebrew-node-0.6.0-fM0b/node-v0.6.0/out/Release/deps/uv/uv.a(ares_nowarn.o)" - no debug information available for "ares_nowarn.c".

warning: Could not find object file "/private/tmp/homebrew-node-0.6.0-fM0b/node-v0.6.0/out/Release/deps/uv/uv.a(ares_options.o)" - no debug information available for "ares_options.c".

warning: Could not find object file "/private/tmp/homebrew-node-0.6.0-fM0b/node-v0.6.0/out/Release/deps/uv/uv.a(ares_parse_a_reply.o)" - no debug information available for "ares_parse_a_reply.c".

warning: Could not find object file "/private/tmp/homebrew-node-0.6.0-fM0b/node-v0.6.0/out/Release/deps/uv/uv.a(ares_parse_aaaa_reply.o)" - no debug information available for "ares_parse_aaaa_reply.c".


warning: Could not find object file "/private/tmp/homebrew-node-0.6.0-fM0b/node-v0.6.0/out/Release/deps/uv/uv.a(ares_parse_mx_reply.o)" - no debug information available for "ares_parse_mx_reply.c".


warning: Could not find object file "/private/tmp/homebrew-node-0.6.0-fM0b/node-v0.6.0/out/Release/deps/uv/uv.a(ares_parse_ns_reply.o)" - no debug information available for "ares_parse_ns_reply.c".


warning: Could not find object file "/private/tmp/homebrew-node-0.6.0-fM0b/node-v0.6.0/out/Release/deps/uv/uv.a(ares_parse_ptr_reply.o)" - no debug information available for "ares_parse_ptr_reply.c".


warning: Could not find object file "/private/tmp/homebrew-node-0.6.0-fM0b/node-v0.6.0/out/Release/deps/uv/uv.a(ares_parse_srv_reply.o)" - no debug information available for "ares_parse_srv_reply.c".

warning: Could not find object file "/private/tmp/homebrew-node-0.6.0-fM0b/node-v0.6.0/out/Release/deps/uv/uv.a(ares_parse_txt_reply.o)" - no debug information available for "ares_parse_txt_reply.c".

warning: Could not find object file "/private/tmp/homebrew-node-0.6.0-fM0b/node-v0.6.0/out/Release/deps/uv/uv.a(ares_process.o)" - no debug information available for "ares_process.c".

warning: Could not find object file "/private/tmp/homebrew-node-0.6.0-fM0b/node-v0.6.0/out/Release/deps/uv/uv.a(ares_query.o)" - no debug information available for "ares_query.c".

warning: Could not find object file "/private/tmp/homebrew-node-0.6.0-fM0b/node-v0.6.0/out/Release/deps/uv/uv.a(ares_search.o)" - no debug information available for "ares_search.c".

warning: Could not find object file "/private/tmp/homebrew-node-0.6.0-fM0b/node-v0.6.0/out/Release/deps/uv/uv.a(ares_send.o)" - no debug information available for "ares_send.c".

warning: Could not find object file "/private/tmp/homebrew-node-0.6.0-fM0b/node-v0.6.0/out/Release/deps/uv/uv.a(bitncmp.o)" - no debug information available for "bitncmp.c".

warning: Could not find object file "/private/tmp/homebrew-node-0.6.0-fM0b/node-v0.6.0/out/Release/deps/uv/uv.a(inet_net_pton.o)" - no debug information available for "inet_net_pton.c".

(gdb) run
Starting program: /usr/local/bin/node simple.js
Reading symbols for shared libraries ++++++++++.......................................................................................................................... done

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000948
0x0000000100056435 in v8::HandleScope::RawClose ()
(gdb) backtrace
#0  0x0000000100056435 in v8::HandleScope::RawClose ()
#1  0x0000000100010117 in node::Stat ()
#2  0x000000010007225e in v8::internal::Builtin_HandleApiCall ()
Previous frame inner to this frame (gdb could not unwind past this frame)
(gdb) 
Greg Ferrell

Also, i just did a make install node from source and get the same errors.

ry
ry commented November 09, 2011

What version of GCC?

ry
ry commented November 09, 2011

I can't repeat. Strange bug.

@DTrejo is also seeing this same problem.

ry
ry commented November 09, 2011

Please give the output of

otool -L `which node`
Greg Ferrell
$ otool -L `which node`
/usr/local/bin/node:
    /usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.5)
    /System/Library/Frameworks/Carbon.framework/Versions/A/Carbon (compatibility version 2.0.0, current version 153.0.0)
    /usr/lib/libssl.0.9.8.dylib (compatibility version 0.9.8, current version 44.0.0)
    /usr/lib/libcrypto.0.9.8.dylib (compatibility version 0.9.8, current version 44.0.0)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 159.1.0)
    /usr/lib/libutil.dylib (compatibility version 1.0.0, current version 1.0.0)
    /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 52.0.0)
    /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1105.0.0)
    /System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices (compatibility version 1.0.0, current version 53.0.0)
    /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 635.15.0)
    /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices (compatibility version 1.0.0, current version 41.0.0)

$ gcc --version
i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2335.15.00)

Some of those warnings went away after i did a make install of the tarball:
$ gdb --args node simple.js
GNU gdb 6.3.50-20050815 (Apple version gdb-1705) (Fri Jul  1 10:50:06 UTC 2011)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "x86_64-apple-darwin"...Reading symbols for shared libraries ........... done

(gdb) run
Starting program: /usr/local/bin/node simple.js
Reading symbols for shared libraries ++++++++++.......................................................................................................................... done

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000948
0x0000000100056235 in v8::HandleScope::RawClose () at node_crypto.h:166
166     return ss;
(gdb) backtrace
#0  0x0000000100056235 in v8::HandleScope::RawClose () at node_crypto.h:166
#1  0x000000010000ff17 in v8::HandleScope::Close<v8::Object> () at /Users/gferrell/stuff/software_sources/node/node-v0.6.0/deps/v8/include/v8.h:3953
#2  0x000000010000ff17 in Stat (args=@0x7fff5fbff4a8) at v8.h:410
#3  0x000000010007205e in v8::internal::Builtin_HandleApiCall () at node_crypto.h:166
Previous frame inner to this frame (gdb could not unwind past this frame)
ry
ry commented November 09, 2011

@mraleph found this https://gist.github.com/1352731

We think it's related to _LARGEFILE_SOURCE or _FILE_OFFSET_BITS=64.

What CPU do you have?

Greg Ferrell
ry
ry commented November 09, 2011

Is the node binary 32 bit or 64?

file `which node`
Greg Ferrell

/usr/local/bin/node: Mach-O 64-bit executable x86_64

ry
ry commented November 09, 2011

Please show the assembly for uv_fs_stat you can get it like this:

% gdb --args ./node
GNU gdb 6.3.50-20050815 (Apple version gdb-1515) (Sat Jan 15 08:33:48 UTC 2011)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "x86_64-apple-darwin"...Reading symbols for shared libraries ........... done

(gdb) disassemble uv_fs_stat

On my (working) binary it is

Dump of assembler code for function uv_fs_stat:
0x0000000100304e15 <uv_fs_stat+0>:  push   %rbp
0x0000000100304e16 <uv_fs_stat+1>:  mov    %rsp,%rbp
0x0000000100304e19 <uv_fs_stat+4>:  sub    $0x40,%rsp
0x0000000100304e1d <uv_fs_stat+8>:  mov    %rdi,-0x18(%rbp)
0x0000000100304e21 <uv_fs_stat+12>: mov    %rsi,-0x20(%rbp)
0x0000000100304e25 <uv_fs_stat+16>: mov    %rdx,-0x28(%rbp)
0x0000000100304e29 <uv_fs_stat+20>: mov    %rcx,-0x30(%rbp)
0x0000000100304e2d <uv_fs_stat+24>: mov    -0x30(%rbp),%rax
0x0000000100304e31 <uv_fs_stat+28>: mov    -0x28(%rbp),%rcx
0x0000000100304e35 <uv_fs_stat+32>: mov    -0x20(%rbp),%rsi
0x0000000100304e39 <uv_fs_stat+36>: mov    -0x18(%rbp),%rdi
0x0000000100304e3d <uv_fs_stat+40>: mov    %rax,%r8
0x0000000100304e40 <uv_fs_stat+43>: mov    $0x6,%edx
0x0000000100304e45 <uv_fs_stat+48>: callq  0x100303fa7 <uv_fs_req_init>
0x0000000100304e4a <uv_fs_stat+53>: mov    -0x28(%rbp),%rdi
0x0000000100304e4e <uv_fs_stat+57>: callq  0x100328202 <dyld_stub_strdup>
0x0000000100304e53 <uv_fs_stat+62>: mov    %rax,-0x10(%rbp)
0x0000000100304e57 <uv_fs_stat+66>: mov    -0x28(%rbp),%rdi
0x0000000100304e5b <uv_fs_stat+70>: callq  0x100328214 <dyld_stub_strlen>
0x0000000100304e60 <uv_fs_stat+75>: mov    %eax,-0x4(%rbp)
0x0000000100304e63 <uv_fs_stat+78>: cmpl   $0x0,-0x4(%rbp)
0x0000000100304e67 <uv_fs_stat+82>: jle    0x100304e93 <uv_fs_stat+126>
0x0000000100304e69 <uv_fs_stat+84>: mov    -0x28(%rbp),%rdx
0x0000000100304e6d <uv_fs_stat+88>: dec    %rdx
0x0000000100304e70 <uv_fs_stat+91>: mov    -0x4(%rbp),%eax
0x0000000100304e73 <uv_fs_stat+94>: cltq   
0x0000000100304e75 <uv_fs_stat+96>: lea    (%rdx,%rax,1),%rax
0x0000000100304e79 <uv_fs_stat+100>:    movzbl (%rax),%eax
0x0000000100304e7c <uv_fs_stat+103>:    cmp    $0x5c,%al
0x0000000100304e7e <uv_fs_stat+105>:    jne    0x100304e93 <uv_fs_stat+126>
0x0000000100304e80 <uv_fs_stat+107>:    mov    -0x10(%rbp),%rdx
0x0000000100304e84 <uv_fs_stat+111>:    dec    %rdx
0x0000000100304e87 <uv_fs_stat+114>:    mov    -0x4(%rbp),%eax
0x0000000100304e8a <uv_fs_stat+117>:    cltq   
0x0000000100304e8c <uv_fs_stat+119>:    lea    (%rdx,%rax,1),%rax
0x0000000100304e90 <uv_fs_stat+123>:    movb   $0x0,(%rax)
0x0000000100304e93 <uv_fs_stat+126>:    cmpq   $0x0,-0x30(%rbp)
0x0000000100304e98 <uv_fs_stat+131>:    je     0x100304f03 <uv_fs_stat+238>
0x0000000100304e9a <uv_fs_stat+133>:    mov    -0x18(%rbp),%rdi
0x0000000100304e9e <uv_fs_stat+137>:    callq  0x100302d16 <uv_ref>
0x0000000100304ea3 <uv_fs_stat+142>:    mov    -0x20(%rbp),%rcx
0x0000000100304ea7 <uv_fs_stat+146>:    mov    -0x10(%rbp),%rdi
0x0000000100304eab <uv_fs_stat+150>:    lea    -0xd7c(%rip),%rdx        # 0x100304136 <uv__fs_after>
0x0000000100304eb2 <uv_fs_stat+157>:    mov    $0x0,%esi
0x0000000100304eb7 <uv_fs_stat+162>:    callq  0x10031a0d9 <eio_stat>
0x0000000100304ebc <uv_fs_stat+167>:    mov    %rax,%rdx
0x0000000100304ebf <uv_fs_stat+170>:    mov    -0x20(%rbp),%rax
0x0000000100304ec3 <uv_fs_stat+174>:    mov    %rdx,0xd8(%rax)
0x0000000100304eca <uv_fs_stat+181>:    mov    -0x10(%rbp),%rdi
0x0000000100304ece <uv_fs_stat+185>:    callq  0x100327e54 <dyld_stub_free>
0x0000000100304ed3 <uv_fs_stat+190>:    mov    -0x20(%rbp),%rax
0x0000000100304ed7 <uv_fs_stat+194>:    mov    0xd8(%rax),%rax
0x0000000100304ede <uv_fs_stat+201>:    test   %rax,%rax
0x0000000100304ee1 <uv_fs_stat+204>:    jne    0x100304efa <uv_fs_stat+229>
0x0000000100304ee3 <uv_fs_stat+206>:    mov    -0x18(%rbp),%rdi
0x0000000100304ee7 <uv_fs_stat+210>:    mov    $0xc,%esi
0x0000000100304eec <uv_fs_stat+215>:    callq  0x10030df83 <uv__set_sys_error>
0x0000000100304ef1 <uv_fs_stat+220>:    movl   $0xffffffff,-0x34(%rbp)
0x0000000100304ef8 <uv_fs_stat+227>:    jmp    0x100304f69 <uv_fs_stat+340>
0x0000000100304efa <uv_fs_stat+229>:    movl   $0x0,-0x34(%rbp)
0x0000000100304f01 <uv_fs_stat+236>:    jmp    0x100304f69 <uv_fs_stat+340>
0x0000000100304f03 <uv_fs_stat+238>:    mov    -0x20(%rbp),%rsi
0x0000000100304f07 <uv_fs_stat+242>:    add    $0x48,%rsi
0x0000000100304f0b <uv_fs_stat+246>:    mov    -0x10(%rbp),%rdi
0x0000000100304f0f <uv_fs_stat+250>:    callq  0x1003281e4 <dyld_stub_stat$INODE64>
0x0000000100304f14 <uv_fs_stat+255>:    movslq %eax,%rdx
0x0000000100304f17 <uv_fs_stat+258>:    mov    -0x20(%rbp),%rax
0x0000000100304f1b <uv_fs_stat+262>:    mov    %rdx,0x28(%rax)
0x0000000100304f1f <uv_fs_stat+266>:    mov    -0x10(%rbp),%rdi
0x0000000100304f23 <uv_fs_stat+270>:    callq  0x100327e54 <dyld_stub_free>
0x0000000100304f28 <uv_fs_stat+275>:    mov    -0x20(%rbp),%rax
0x0000000100304f2c <uv_fs_stat+279>:    mov    0x28(%rax),%rax
0x0000000100304f30 <uv_fs_stat+283>:    test   %rax,%rax
0x0000000100304f33 <uv_fs_stat+286>:    jns    0x100304f4e <uv_fs_stat+313>
0x0000000100304f35 <uv_fs_stat+288>:    callq  0x100327cd4 <dyld_stub___error>
0x0000000100304f3a <uv_fs_stat+293>:    mov    (%rax),%esi
0x0000000100304f3c <uv_fs_stat+295>:    mov    -0x18(%rbp),%rdi
0x0000000100304f40 <uv_fs_stat+299>:    callq  0x10030df83 <uv__set_sys_error>
0x0000000100304f45 <uv_fs_stat+304>:    movl   $0xffffffff,-0x34(%rbp)
0x0000000100304f4c <uv_fs_stat+311>:    jmp    0x100304f69 <uv_fs_stat+340>
0x0000000100304f4e <uv_fs_stat+313>:    mov    -0x20(%rbp),%rdx
0x0000000100304f52 <uv_fs_stat+317>:    add    $0x48,%rdx
0x0000000100304f56 <uv_fs_stat+321>:    mov    -0x20(%rbp),%rax
0x0000000100304f5a <uv_fs_stat+325>:    mov    %rdx,0x30(%rax)
0x0000000100304f5e <uv_fs_stat+329>:    mov    -0x20(%rbp),%rax
0x0000000100304f62 <uv_fs_stat+333>:    mov    0x28(%rax),%rax
0x0000000100304f66 <uv_fs_stat+337>:    mov    %eax,-0x34(%rbp)
0x0000000100304f69 <uv_fs_stat+340>:    mov    -0x34(%rbp),%eax
0x0000000100304f6c <uv_fs_stat+343>:    leaveq 
0x0000000100304f6d <uv_fs_stat+344>:    retq   
End of assembler dump.
Greg Ferrell
$ gdb --args /usr/local/bin/node
GNU gdb 6.3.50-20050815 (Apple version gdb-1705) (Fri Jul  1 10:50:06 UTC 2011)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "x86_64-apple-darwin"...Reading symbols for shared libraries ........... done

(gdb) disassemble uv_fs_stat
Dump of assembler code for function uv_fs_stat:
0x0000000100256e70 <uv_fs_stat+0>:  push   %rbp
0x0000000100256e71 <uv_fs_stat+1>:  mov    %rsp,%rbp
0x0000000100256e74 <uv_fs_stat+4>:  sub    $0x50,%rsp
0x0000000100256e78 <uv_fs_stat+8>:  mov    %rdx,%rax
0x0000000100256e7b <uv_fs_stat+11>: mov    %rdi,-0x8(%rbp)
0x0000000100256e7f <uv_fs_stat+15>: mov    %rsi,-0x10(%rbp)
0x0000000100256e83 <uv_fs_stat+19>: mov    %rax,-0x18(%rbp)
0x0000000100256e87 <uv_fs_stat+23>: mov    %rcx,-0x20(%rbp)
0x0000000100256e8b <uv_fs_stat+27>: mov    -0x8(%rbp),%rax
0x0000000100256e8f <uv_fs_stat+31>: mov    -0x10(%rbp),%rcx
0x0000000100256e93 <uv_fs_stat+35>: mov    -0x18(%rbp),%rsi
0x0000000100256e97 <uv_fs_stat+39>: mov    -0x20(%rbp),%rdi
0x0000000100256e9b <uv_fs_stat+43>: mov    $0x6,%r8d
0x0000000100256ea1 <uv_fs_stat+49>: mov    %rdi,-0x40(%rbp)
0x0000000100256ea5 <uv_fs_stat+53>: mov    %rax,%rdi
0x0000000100256ea8 <uv_fs_stat+56>: mov    %rsi,-0x48(%rbp)
0x0000000100256eac <uv_fs_stat+60>: mov    %rcx,%rsi
0x0000000100256eaf <uv_fs_stat+63>: mov    %r8d,%edx
0x0000000100256eb2 <uv_fs_stat+66>: mov    -0x48(%rbp),%rcx
0x0000000100256eb6 <uv_fs_stat+70>: mov    -0x40(%rbp),%r8
0x0000000100256eba <uv_fs_stat+74>: callq  0x100255af0 <uv_fs_req_init>
0x0000000100256ebf <uv_fs_stat+79>: mov    -0x18(%rbp),%rax
0x0000000100256ec3 <uv_fs_stat+83>: mov    %rax,%rdi
0x0000000100256ec6 <uv_fs_stat+86>: callq  0x100285a1e <dyld_stub_strdup>
0x0000000100256ecb <uv_fs_stat+91>: mov    %rax,-0x30(%rbp)
0x0000000100256ecf <uv_fs_stat+95>: mov    -0x18(%rbp),%rax
0x0000000100256ed3 <uv_fs_stat+99>: mov    %rax,%rdi
0x0000000100256ed6 <uv_fs_stat+102>:    callq  0x100285a30 <dyld_stub_strlen>
0x0000000100256edb <uv_fs_stat+107>:    mov    %eax,-0x34(%rbp)
0x0000000100256ede <uv_fs_stat+110>:    mov    -0x34(%rbp),%eax
0x0000000100256ee1 <uv_fs_stat+113>:    cmp    $0x0,%eax
0x0000000100256ee4 <uv_fs_stat+116>:    jle    0x100256f0b <uv_fs_stat+155>
0x0000000100256ee6 <uv_fs_stat+118>:    mov    -0x34(%rbp),%eax
0x0000000100256ee9 <uv_fs_stat+121>:    sub    $0x1,%eax
0x0000000100256eec <uv_fs_stat+124>:    mov    -0x18(%rbp),%rcx
0x0000000100256ef0 <uv_fs_stat+128>:    movslq %eax,%rax
0x0000000100256ef3 <uv_fs_stat+131>:    mov    (%rcx,%rax,1),%al
0x0000000100256ef6 <uv_fs_stat+134>:    cmp    $0x5c,%al
0x0000000100256ef8 <uv_fs_stat+136>:    jne    0x100256f0b <uv_fs_stat+155>
0x0000000100256efa <uv_fs_stat+138>:    mov    -0x34(%rbp),%eax
0x0000000100256efd <uv_fs_stat+141>:    sub    $0x1,%eax
0x0000000100256f00 <uv_fs_stat+144>:    mov    -0x30(%rbp),%rcx
0x0000000100256f04 <uv_fs_stat+148>:    movslq %eax,%rax
0x0000000100256f07 <uv_fs_stat+151>:    movb   $0x0,(%rcx,%rax,1)
0x0000000100256f0b <uv_fs_stat+155>:    mov    -0x20(%rbp),%rax
0x0000000100256f0f <uv_fs_stat+159>:    cmp    $0x0,%rax
0x0000000100256f13 <uv_fs_stat+163>:    je     0x100256f9e <uv_fs_stat+302>
0x0000000100256f19 <uv_fs_stat+169>:    mov    -0x8(%rbp),%rax
0x0000000100256f1d <uv_fs_stat+173>:    mov    %rax,%rdi
0x0000000100256f20 <uv_fs_stat+176>:    callq  0x1002540d0 <uv_ref>
0x0000000100256f25 <uv_fs_stat+181>:    mov    -0x30(%rbp),%rax
0x0000000100256f29 <uv_fs_stat+185>:    mov    -0x10(%rbp),%rcx
0x0000000100256f2d <uv_fs_stat+189>:    mov    $0x0,%edx
0x0000000100256f32 <uv_fs_stat+194>:    lea    -0x1279(%rip),%rdi        # 0x100255cc0 <uv__fs_after>
0x0000000100256f39 <uv_fs_stat+201>:    mov    %rdi,-0x50(%rbp)
0x0000000100256f3d <uv_fs_stat+205>:    mov    %rax,%rdi
0x0000000100256f40 <uv_fs_stat+208>:    mov    %edx,%esi
0x0000000100256f42 <uv_fs_stat+210>:    mov    -0x50(%rbp),%rdx
0x0000000100256f46 <uv_fs_stat+214>:    callq  0x1002728b0 <eio_stat>
0x0000000100256f4b <uv_fs_stat+219>:    mov    -0x10(%rbp),%rcx
0x0000000100256f4f <uv_fs_stat+223>:    mov    %rax,0xd8(%rcx)
0x0000000100256f56 <uv_fs_stat+230>:    mov    -0x30(%rbp),%rax
0x0000000100256f5a <uv_fs_stat+234>:    mov    %rax,%rdi
0x0000000100256f5d <uv_fs_stat+237>:    callq  0x100285682 <dyld_stub_free>
0x0000000100256f62 <uv_fs_stat+242>:    mov    -0x10(%rbp),%rax
0x0000000100256f66 <uv_fs_stat+246>:    mov    0xd8(%rax),%rax
0x0000000100256f6d <uv_fs_stat+253>:    cmp    $0x0,%rax
0x0000000100256f71 <uv_fs_stat+257>:    jne    0x100256f92 <uv_fs_stat+290>
0x0000000100256f73 <uv_fs_stat+259>:    mov    -0x8(%rbp),%rax
0x0000000100256f77 <uv_fs_stat+263>:    mov    $0xc,%ecx
0x0000000100256f7c <uv_fs_stat+268>:    mov    %rax,%rdi
0x0000000100256f7f <uv_fs_stat+271>:    mov    %ecx,%esi
0x0000000100256f81 <uv_fs_stat+273>:    callq  0x100262bf0 <uv__set_sys_error>
0x0000000100256f86 <uv_fs_stat+278>:    movl   $0xffffffff,-0x28(%rbp)
0x0000000100256f8d <uv_fs_stat+285>:    jmpq   0x100257027 <uv_fs_stat+439>
0x0000000100256f92 <uv_fs_stat+290>:    movl   $0x0,-0x28(%rbp)
0x0000000100256f99 <uv_fs_stat+297>:    jmpq   0x100257027 <uv_fs_stat+439>
0x0000000100256f9e <uv_fs_stat+302>:    mov    -0x10(%rbp),%rax
0x0000000100256fa2 <uv_fs_stat+306>:    mov    $0x48,%rcx
0x0000000100256fac <uv_fs_stat+316>:    add    %rcx,%rax
0x0000000100256faf <uv_fs_stat+319>:    mov    -0x30(%rbp),%rcx
0x0000000100256fb3 <uv_fs_stat+323>:    mov    %rcx,%rdi
0x0000000100256fb6 <uv_fs_stat+326>:    mov    %rax,%rsi
0x0000000100256fb9 <uv_fs_stat+329>:    callq  0x100285a00 <dyld_stub_stat$INODE64>
0x0000000100256fbe <uv_fs_stat+334>:    mov    %eax,%ecx
0x0000000100256fc0 <uv_fs_stat+336>:    movslq %ecx,%rcx
0x0000000100256fc3 <uv_fs_stat+339>:    mov    -0x10(%rbp),%rdx
0x0000000100256fc7 <uv_fs_stat+343>:    mov    %rcx,0x28(%rdx)
0x0000000100256fcb <uv_fs_stat+347>:    mov    -0x30(%rbp),%rcx
0x0000000100256fcf <uv_fs_stat+351>:    mov    %rcx,%rdi
0x0000000100256fd2 <uv_fs_stat+354>:    callq  0x100285682 <dyld_stub_free>
0x0000000100256fd7 <uv_fs_stat+359>:    mov    -0x10(%rbp),%rax
0x0000000100256fdb <uv_fs_stat+363>:    mov    0x28(%rax),%rax
0x0000000100256fdf <uv_fs_stat+367>:    cmp    $0x0,%rax
0x0000000100256fe3 <uv_fs_stat+371>:    jge    0x100257003 <uv_fs_stat+403>
0x0000000100256fe5 <uv_fs_stat+373>:    callq  0x1002854f0 <dyld_stub___error>
0x0000000100256fea <uv_fs_stat+378>:    mov    (%rax),%eax
0x0000000100256fec <uv_fs_stat+380>:    mov    -0x8(%rbp),%rcx
0x0000000100256ff0 <uv_fs_stat+384>:    mov    %rcx,%rdi
0x0000000100256ff3 <uv_fs_stat+387>:    mov    %eax,%esi
0x0000000100256ff5 <uv_fs_stat+389>:    callq  0x100262bf0 <uv__set_sys_error>
0x0000000100256ffa <uv_fs_stat+394>:    movl   $0xffffffff,-0x28(%rbp)
0x0000000100257001 <uv_fs_stat+401>:    jmp    0x100257027 <uv_fs_stat+439>
0x0000000100257003 <uv_fs_stat+403>:    mov    -0x10(%rbp),%rax
0x0000000100257007 <uv_fs_stat+407>:    mov    $0x48,%rcx
0x0000000100257011 <uv_fs_stat+417>:    add    %rcx,%rax
0x0000000100257014 <uv_fs_stat+420>:    mov    -0x10(%rbp),%rcx
0x0000000100257018 <uv_fs_stat+424>:    mov    %rax,0x30(%rcx)
0x000000010025701c <uv_fs_stat+428>:    mov    -0x10(%rbp),%rax
0x0000000100257020 <uv_fs_stat+432>:    mov    0x28(%rax),%rax
0x0000000100257024 <uv_fs_stat+436>:    mov    %eax,-0x28(%rbp)
0x0000000100257027 <uv_fs_stat+439>:    mov    -0x28(%rbp),%eax
0x000000010025702a <uv_fs_stat+442>:    mov    %eax,-0x24(%rbp)
0x000000010025702d <uv_fs_stat+445>:    mov    -0x24(%rbp),%eax
0x0000000100257030 <uv_fs_stat+448>:    add    $0x50,%rsp
0x0000000100257034 <uv_fs_stat+452>:    pop    %rbp
0x0000000100257035 <uv_fs_stat+453>:    retq   
End of assembler dump.
(gdb) 
Gavin Gilmour

Also experiencing this exact issue for what it's worth. Almost identical setup except on a 2007 2.4ghz core 2 duo 24" iMac.

Charles Lawrence

Also getting this issue on Snow Leopard 10.6.8 with node built from source and from homebrew.

gcc -v:
Target: i686-apple-darwin10
Configured with: /var/tmp/gcc/gcc-5666.3~123/src/configure --disable-checking --enable-werror --prefix=/usr --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ --with-slibdir=/usr/lib --build=i686-apple-darwin10 --program-prefix=i686-apple-darwin10- --host=x86_64-apple-darwin10 --target=i686-apple-darwin10 --with-gxx-include-dir=/include/c++/4.2.1
Thread model: posix
gcc version 4.2.1 (Apple Inc. build 5666) (dot 3)

ry
ry commented November 11, 2011

can someone please provide me a login onto a box experiencing this issue?

Greg Ferrell

I am just on my personal machine. I don't think my ISP will allow a remote SSH into it, but ill see if there is some way i can do that.

Kenneth Kalmer

Maybe chime in over here too (Homebrew/homebrew#8460)

Manual builds as well as brew install node show this segfault when trying to install npm. Thinking the underlying issue is with Snow Leopards SSL maybe (0.9.8r), but that is purely speculative.

I'll give @ry access to my machine again over the coming days to help trace this.

Kenneth Kalmer

Adding some more info to the mix.

gdb --args /Users/kenneth/ryan-work/node-v0.6.0/node bin/read-package-json.js package.json engines.node        
GNU gdb 6.3.50-20050815 (Apple version gdb-1515) (Sat Jan 15 08:33:48 UTC 2011)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "x86_64-apple-darwin"...Reading symbols for shared libraries ........... done

(gdb) run
Starting program: /Users/kenneth/ryan-work/node-v0.6.0/node bin/read-package-json.js package.json engines.node
Reading symbols for shared libraries .++++++++++.................................................................................... done

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000948
0x0000000100064cb3 in v8::HandleScope::RawClose ()
(gdb) backtrace
#0  0x0000000100064cb3 in v8::HandleScope::RawClose ()
#1  0x000000010001f4bb in Close<v8::Object> [inlined] () at /Users/kenneth/ryan-work/node-v0.6.0/deps/v8/include/v8.h:410
Previous frame inner to this frame (gdb could not unwind past this frame)
otool -L /Users/kenneth/ryan-work/node-v0.6.0/node                                                             
/Users/kenneth/ryan-work/node-v0.6.0/node:
    /usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.3)
    /System/Library/Frameworks/Carbon.framework/Versions/A/Carbon (compatibility version 2.0.0, current version 152.0.0)
    /usr/lib/libssl.0.9.8.dylib (compatibility version 0.9.8, current version 0.9.8)
    /usr/lib/libcrypto.0.9.8.dylib (compatibility version 0.9.8, current version 0.9.8)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.11)
    /usr/lib/libutil.dylib (compatibility version 1.0.0, current version 1.0.0)
    /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.9.0)
    /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 830.0.0)
    /System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices (compatibility version 1.0.0, current version 44.0.0)
    /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 550.44.0)
    /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices (compatibility version 1.0.0, current version 38.0.0)
Charles Lawrence

Getting the same segmentation fault with 0.6.1 built from source.

ry
ry commented November 11, 2011

just for sanity check you're not getting the segfault with the v0.6.1 .pkg file? http://nodejs.org/dist/v0.6.1/node-v0.6.1.pkg

dn
dn commented November 12, 2011

@ry got the same issue as above, but .pkg worked for me

Gavin Gilmour

v0.6.1 .pkg working fine here!

Kenneth Kalmer

Managed to install npm now with the 0.6.1.pkg file, will build from source as well and report. (Snow Leopard)

Greg Ferrell

pkg file works! Thanks Ryan! Do we need to test a different way to help diagnose?

Paddy Byers

You need to compile with -D__DARWIN_64_BIT_INO_T

On 64 bit Darwin, it uses its own stat struct layout, but the headers don'r default to that.

Took me a day to find that :(

Greg Ferrell

Tried the 0.6.1 from brew and it still fails with the same issue. You guys might already know, but just in case. pkg file works fine for me.

Paddy Byers

I'm pretty sure that your issue is that you're compiling for x86_64 but it is picking up the stat struct for 32 bit.

The .pkg will be built for 32 bit I think which is why it works.

Can you try adding -D__DARWIN_64_BIT_INO_T to the compiler flags?

Nick Retallack

@paddybyers how do you add compiler flags? The configure script doesn't seem to take an option for that.

Paddy Byers
ry
ry commented November 15, 2011

I've never heard of __DARWIN_64_BIT_INO_T but here's the patch for Paddy's suggestion: https://gist.github.com/b48ca38bbc52f7c6a563

Apply it like this:

curl https://raw.github.com/gist/b48ca38bbc52f7c6a563/ece01867c8ab0d86ca5432e43fae9f4a2e7080e6/64-bit-ino-t.diff | patch -p1
make distclean
./configure
make
Paddy Byers

I tried to reproduce the problem today with homebrew and I wasn't able to. But I definitely had the problem with Xcode 4.1 (4B110), having generated the project files with gyp. It is using llvm-gcc-4.2 and compiling for 64 bit instead of the default 32/64 bit. But I'm sure it's more to do with the linker than compiler, but Xcode is a bit opaque about exactly what it's linking to.

We can't do a proper fix for gyp or waf until we know exactly what platform characteristic is causing it to pick up the version of the libraries with the x64-specific struct layout.

ry
ry commented November 17, 2011

@gregferrell @kennethkalmer @gaving can you please try the above patch?

David Townsend

If you add

ENV.append_to_cflags '-D__DARWIN_64_BIT_INO_T'

to the beginning of the install method in the formula it does fix the segfault.

Ben Noordhuis bnoordhuis referenced this issue from a commit in bnoordhuis/node November 18, 2011
Ben Noordhuis build: compile with -D__DARWIN_64_BIT_INO_T on OS X
Fixes a struct stat size mismatch on 64 bits machines that made Node crash with
a EXC_BAD_ACCESS on startup.

Fixes #2061. Solution proposed by Paddy Byers.
8bed0a3
Ben Noordhuis bnoordhuis closed this issue from a commit November 18, 2011
Ben Noordhuis build: compile with -D__DARWIN_64_BIT_INO_T on OS X
Fixes a struct stat size mismatch on 64 bits machines that made Node crash with
a EXC_BAD_ACCESS on startup.

Fixes #2061. Solution proposed by Paddy Byers.
8bed0a3
Ben Noordhuis bnoordhuis closed this in 8bed0a3 November 18, 2011
Ben Noordhuis

Can someone verify this patch?

It's also available as a branch: git fetch origin && git checkout origin/issue2061

Please do a make distclean after applying / checking it out.

Paddy Byers

The problem is that I don't really know when this flag needs to be added. It's definitely only on x86_64, but maybe only on Lion also. The issue is that homebrew is using different toolchain settings from what node.js maintains and tests in waf and gyp. Until we know exactly what compiler/linker and platform combination trigger the problem we could be making things worse, not better.

I think the waf/gyp builds force ia32 so they don't suffer from the problem.

That said, it's really a toolchain problem; node should be free to use a system-provided struct definition - stat - without having to know the idiosyncrasies of which structure is used on which OS version and which processor, etc.

I suggest:

  • someone looks at improving the standard configuration (maybe this is only done post-0.6, for gyp only) to detect host+target architecture and set the flags appropriately; then there can be a systematic evaluation of what flags are needed where;

  • the homebrew package maintainer looks at solving the problem for the homebrew package. If homebrew is providing the toolchain configuration, then I think the issue needs to be addressed there.

Paddy Byers

Just to add to the confusion, we've got these definitions:

https://github.com/joyent/node/blob/v0.6/src/node.h#L147

so any fix isn't just confined to the uv makefile.

Ben Noordhuis bnoordhuis reopened this November 18, 2011
Greg Ferrell

I am sorry that i got back late to this. I tried 0.6.0 source compiled with this patch
#2061 (comment)
and it appears to fix the segfault issue.

Ben Noordhuis bnoordhuis referenced this issue from a commit November 18, 2011
Commit has since been removed from the repository and is no longer available.
Ben Noordhuis bnoordhuis closed this issue from a commit November 18, 2011
Ben Noordhuis build: compile with -D__DARWIN_64_BIT_INO_T on OS X
Fixes a struct stat size mismatch on 64 bits machines that made Node crash with
a EXC_BAD_ACCESS on startup.

Fixes #2061. Solution proposed by Paddy Byers.
f004d5a
Ben Noordhuis bnoordhuis closed this in f004d5a November 18, 2011
Paddy Byers

@gregferrell: I think there is an underlying homebrew issue here that we've worked around but I'd still like to understand. So is it possible please to capture a log of the brew build that creates the broken binary?

if you uninstall (brew uninstall node) then capture the build log with

brew install node -v &> log

and attach the log?

The output of brew --env would be useful as well please.

Thanks - Paddy

Greg Ferrell

Sure. However, I've most recently used the package installer, so brew probably wont be able to uninstall that, no? Ill see what i can do and post back here.

Greg Ferrell

Ok, I made a gist of this because the output log is huge. https://gist.github.com/1379136

And my brew --env

CC: /usr/bin/llvm-gcc => /usr/llvm-gcc-4.2/bin/llvm-gcc-4.2
CXX: /usr/bin/llvm-g++ => /usr/llvm-gcc-4.2/bin/llvm-g++-4.2
LD: /usr/bin/llvm-gcc => /usr/llvm-gcc-4.2/bin/llvm-gcc-4.2
CFLAGS: -O3 -march=core2 -msse4.1 -w -pipe
CXXFLAGS: -O3 -march=core2 -msse4.1 -w -pipe
MAKEFLAGS: -j2
Paddy Byers

Thanks

Ben Noordhuis

Reopening, turns out this issue isn't fixed after all: http://groups.google.com/group/nodejs/browse_thread/thread/e4bbdec19f281746

Ben Noordhuis bnoordhuis reopened this November 21, 2011
Paddy Byers

I spent a few hours at the weekend trying to create a standalone example of the problem but failed.

The problem I originally fell over was reproducible running any script, even hello-world.js. (Confusingly, it would run REPL quite happily, but a trivial script specified in the command line would cause it to fail.)

The problem happens when node stats the script specified on the commandline. Stat() (node_file.cc) does a SYNC_CALL(stat) which allocates a fs_req_wrap, including embedded stat struct, on the stack.

For some reason there is a mismatch between sizeof(struct stat) as seen by node_file.cc and the platform's stat(), because the call to the underlying stat() then writes beyond the bounds of the struct on the stack and overwrites the HandleScope that's just above it. Then, on returning from Stat() or BuildStatsObject(), the HandleScope::Close() goes wrong.

I tried the combinations of compile flag from Greg's trace but couldn't get the problem to occur in a standalone test. I tried two compiler versions (i686-apple-darwin10 and i686-apple-darwin11) but I didn't reinstall all of Xcode so I probably don't have an identical environment to the others having the problem.

What I know is that sizeof(stat) depends on whether you're building for x86_64 or ia32, and in my case adding the D__DARWIN_64_BIT_INO_T flag resolved it;I assumed that it was compiling against the struct for ia32 but linking against the library for x86-64. It seemed believable because, if I was already building for x86_64 then adding the flag shouldn't have made any difference. However, it's also possible that there was some other problem, and adding the flag masked it just by making the struct bigger.

What I also found out is that the -mmacosx-version-min=10.4 flag also changes the size of the stat struct. We have this flag for some files and not others, and you can definitely cause the same symptoms if node_file.cc has that flag but the linker doesn't. But from Greg's log, this didn't appear to be the problem. But there's definitely an issue here we can address going forward to have consistency in the compiler flags used across the different libraries.

Finally, I can't say for sure that these failures are all the same bug as I saw, but if it's crashing in HandleScope and there's a Stat() call on the stack it certainly looks the same.

alanherod

Apparently, I am having the error described in this issue. Ben Noordhuis suggested that I post a listing of "gcc -v" and a debug backtrace...

gcc -v
Using built-in specs.
Target: i686-apple-darwin9
Configured with: /var/tmp/gcc/gcc-5493~1/src/configure --disable-checking -enable-werror --prefix=/usr --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/$/-4.0/ --with-gxx-include-dir=/include/c++/4.0.0 --with-slibdir=/usr/lib --build=i686-apple-darwin9 --with-arch=apple --with-tune=generic --host=i686-apple-darwin9 --target=i686-apple-darwin9
Thread model: posix
gcc version 4.0.1 (Apple Inc. build 5493)

Next, I performed the following steps:
touch empty.js
gdb --args ./node_g empty.js
run # wait until it crashes
backtrace

(gdb) run
Starting program: /Users/aherod/node2/node/node_g empty.js
Reading symbols for shared libraries +++++++++....................................................................... done

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x00000534
0x000fe5cc in v8::internal::Isolate::logger (this=0x0) at isolate.h:801
801     ASSERT(logger_ != NULL);

backtrace

#0  0x000fe5cc in v8::internal::Isolate::logger (this=0x0) at isolate.h:801
#1  0x0005f375 in v8::HandleScope::RawClose (this=0xbffff0a4, value=0x1015f70) at /Users/aherod/node2/node/deps/v8/src/api.cc:766
#2  0x0000b6bc in v8::HandleScope::Close (this=0xbffff0a4, value={val_ = 0x1015f70}) at v8.h:3954
#3  0x0001f444 in Stat (args=@0xbffff174) at ../src/node_file.cc:410
#4  0x000a3b47 in HandleApiCallHelper (args={ = { = {}, length_ = 3, arguments_ = 0xbffff26c}, }, isolate=0x9f2000) at /Users/aherod/node2/node/deps/v8/src/builtins.cc:1105
#5  0x000a3c35 in Builtin_Impl_HandleApiCall (args={ = { = {}, length_ = 3, arguments_ = 0xbffff26c}, }, isolate=0x9f2000) at /Users/aherod/node2/node/deps/v8/src/builtins.cc:1122
#6  0x000a3c85 in Builtin_HandleApiCall (args={ = { = {}, length_ = 3, arguments_ = 0xbffff26c}, }, isolate=0x9f2000) at /Users/aherod/node2/node/deps/v8/src/builtins.cc:1121
#7  0x00b88696 in ?? ()
#8  0x00ca0404 in ?? ()
#9  0x00c8fcfc in ?? ()
#10 0x00b9bf86 in ?? ()
#11 0x00c89e11 in ?? ()
#12 0x00c94ba5 in ?? ()
#13 0x00c94715 in ?? ()
#14 0x00c95d0f in ?? ()
#15 0x00ba0912 in ?? ()
#16 0x00b9b11a in ?? ()
#17 0x00b8c206 in ?? ()
#18 0x000d2f83 in Invoke (construct=false, func={location_ = 0x1015f64}, receiver={location_ = 0x100f410}, argc=0, args=0x0, has_pending_exception=0xbffff523) at /Users/aherod/node2/node/deps/v8/src/execution.cc:121
#19 0x000d373d in v8::internal::Execution::Call (callable={location_ = 0x1015f64}, receiver={location_ = 0x100f410}, argc=0, args=0x0, pending_exception=0xbffff523, convert_receiver=false) at /Users/aherod/node2/node/deps/v8/src/execution.cc:175
#20 0x0006f298 in v8::Function::Call (this=0x1015f64, recv={val_ = 0x100f410}, argc=0, argv=0x0) at /Users/aherod/node2/node/deps/v8/src/api.cc:3594
#21 0x0000ae33 in Tick () at ../src/node.cc:243
#22 0x0000afb1 in PrepareTick (handle=0x546a60, status=0) at ../src/node.cc:277
#23 0x003aeca6 in uv__prepare (loop=0x548520, w=0x546a8c, revents=16384) at src/unix/core.c:322
#24 0x003bdb8a in ev_invoke_pending (loop=0x548520) at src/unix/ev/ev.c:2143
#25 0x003be032 in ev_run (loop=0x548520, flags=0) at src/unix/ev/ev.c:2428
#26 0x003ae5bf in uv_run (loop=0x5482a0) at src/unix/core.c:192
#27 0x0000ac65 in node::Start (argc=2, argv=0xbffff794) at ../src/node.cc:2478
#28 0x0000258a in main (argc=2, argv=0xbffff794) at ../src/node_main.cc:25

Hopefully, this will help things!

Thank you for all the hard work you all contribute!

Steve Dekorte

(gdb) r server.js
Starting program: /usr/local/bin/node server.js
Reading symbols for shared libraries ++++++++++............................................................................................................................ done
The "sys" module is now called "util". It should have a similar interface.
Reading symbols for shared libraries warning: Could not find object file "/Users/rcollins/projects/node-tokyocabinet/build/default/src/tokyocabinet_1.o" - no debug information available for "../src/tokyocabinet.cc".

.warning: Could not find object file "/Users/steve/Downloads/tokyocabinet-1.4.44/tcutil.o" - no debug information available for "tcutil.c".

warning: Could not find object file "/Users/steve/Downloads/tokyocabinet-1.4.44/tchdb.o" - no debug information available for "tchdb.c".

warning: Could not find object file "/Users/steve/Downloads/tokyocabinet-1.4.44/tcbdb.o" - no debug information available for "tcbdb.c".

warning: Could not find object file "/Users/steve/Downloads/tokyocabinet-1.4.44/tcfdb.o" - no debug information available for "tcfdb.c".

warning: Could not find object file "/Users/steve/Downloads/tokyocabinet-1.4.44/tctdb.o" - no debug information available for "tctdb.c".

warning: Could not find object file "/Users/steve/Downloads/tokyocabinet-1.4.44/tcadb.o" - no debug information available for "tcadb.c".

warning: Could not find object file "/Users/steve/Downloads/tokyocabinet-1.4.44/myconf.o" - no debug information available for "myconf.c".

warning: Could not find object file "/Users/steve/Downloads/tokyocabinet-1.4.44/md5.o" - no debug information available for "md5.c".

.. done

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x00007f0100000000
0x00000001000591c3 in v8::Function::NewInstance () at node_crypto.h:166
166 return ss;

Paddy Byers

@stevedekorte: that looks like a completely different problem based on the information that's there. I think more information would be needed before anyone can work out what's going on. Is this a new problem in v0.6? I note that the tokyocabinet code uses libev directly, so it's unlikely to work out of the box on v0.6.

Russ Bradberry devdazed referenced this issue from a commit in devdazed/node November 25, 2011
Ben Noordhuis build: compile with -D__DARWIN_64_BIT_INO_T on OS X
Fixes a struct stat size mismatch on 64 bits machines that made Node crash with
a EXC_BAD_ACCESS on startup.

Fixes #2061 for gyp builds. Solution proposed by Paddy Byers.
1cf13bc
Ben Noordhuis bnoordhuis reopened this November 25, 2011
Ben Noordhuis

Quick sanity check, is anyone still seeing this issue with the latest v0.6 and/or master branch? If you have to recompile, can you do a make distclean first?

seebees

@bnoordhuis I don't see this issue anymore, but it won't build. Don't know if you want to new issue or what... Back on OSX 10.6.6

$ make distclean && ./configure && make -j6
rm -rf out
rm options.gypi
configure options: {'shared_v8': None, 'openssl_includes': None, 'without_snapshot': None, 'shared_v8_includes': None, 'shared_v8_libpath': None, 'openssl_libpath': None, 'shared_cares_includes': None, 'dest_cpu': None, 'without_ssl': None, 'shared_cares': None, 'prefix': None, 'no_ssl2': None, 'debug': None, 'shared_cares_libpath': None, 'shared_v8_libname': None, 'gdb': None, 'with_dtrace': None}
Package openssl was not found in the pkg-config search path.
Perhaps you should add the directory containing `openssl.pc'
to the PKG_CONFIG_PATH environment variable
No package 'openssl' found
creating  ./options.gypi
['-f', 'make', '/Users/remery/Documents/GIT/node_fork/node.gyp', '-I', '/Users/remery/Documents/GIT/node_fork/common.gypi', '-I', '/Users/remery/Documents/GIT/node_fork/options.gypi', '--depth=.', '--generator-output', '/Users/remery/Documents/GIT/node_fork/out', '-Goutput_dir=/Users/remery/Documents/GIT/node_fork/out', '-Dtarget_arch=ia32', '-Dcomponent=static_library', '-Dlibrary=static_library']
make -C out BUILDTYPE=Release
  CC(target) /Users/remery/Documents/GIT/node_fork/out/Release/obj.target/http_parser/deps/http_parser/http_parser.o

some time later...

libtool: file: /Users/remery/Documents/GIT/node_fork/out/Release/obj.target/v8_base/deps/v8/src/x64/stub-cache-x64.o has no symbols
  LIBTOOL-STATIC /Users/remery/Documents/GIT/node_fork/out/Release/libv8_nosnapshot.a
  LIBTOOL-STATIC /Users/remery/Documents/GIT/node_fork/out/Release/obj.host/deps/v8/tools/gyp/libv8_nosnapshot.a
  CXX(host) /Users/remery/Documents/GIT/node_fork/out/Release/obj.host/mksnapshot/deps/v8/src/mksnapshot.o
  LINK(host) /Users/remery/Documents/GIT/node_fork/out/Release/mksnapshot
  ACTION v8_snapshot_run_mksnapshot /Users/remery/Documents/GIT/node_fork/out/Release/obj.host/geni/snapshot.cc
  ACTION v8_snapshot_run_mksnapshot /Users/remery/Documents/GIT/node_fork/out/Release/obj.target/geni/snapshot.cc
Unable to write to snapshot file "/Users/remery/Documents/GIT/node_fork/out/Release/obj.host/geni/snapshot.cc"
Unable to write to snapshot file "/Users/remery/Documents/GIT/node_fork/out/Release/obj.target/geni/snapshot.cc"
make[1]: *** [/Users/remery/Documents/GIT/node_fork/out/Release/obj.target/geni/snapshot.cc] Error 1
make[1]: *** Waiting for unfinished jobs....
make[1]: *** [/Users/remery/Documents/GIT/node_fork/out/Release/obj.host/geni/snapshot.cc] Error 1
make: *** [all] Error 2
$
Ben Noordhuis

@seebees:

Unable to write to snapshot file "/Users/remery/Documents/GIT/node_fork/out/Release/obj.host/geni/snapshot.cc"

Looks like a permissions issue. Do a chmod -R u+w * from the root of your repository.

seebees

@bnoordhuis It might look that way ;) chmod did not fix it, but rm -r ./out did.

I think this is what you expect:

$ ./out/Release/node ./test/simple/test-http-response-close.js 

node.js:201
        throw e; // process.nextTick error, or 'error' event on first tick
              ^
Error: Cannot find module '/Users/remery/Documents/GIT/node_fork/test/simple/test-http-response-close.js'
    at Function._resolveFilename (module.js:334:11)
    at Function._load (module.js:279:25)
    at Array.0 (module.js:470:10)
    at EventEmitter._tickCallback (node.js:192:40)
$
Ben Noordhuis

Damn, still happening. Can I borrow your laptop one more time?

Greg Ferrell

Just did a brew install of 0.6.2 and its working fine for me. Testing the same scripts I was originally.

Trevor Burnham

I just experienced this for the first time after installing Node 0.6.5 via brew. I'd installed and run Node 0.6.2 via brew with no problems. Downgrading to Node 0.6.4, I experienced the same problem. Reverting to 0.6.2, it still works.

Tried doing a manual install of 0.6.5 with make distclean. Same result.

It's very easy for me to replicate the error:

> npm
Segmentation fault: 11
> coffee
Segmentation fault: 11
Paddy Byers

@TrevorBurnham: backtrace? Just to be sure we're dealing with the same issue.

Thanks

Trevor Burnham

@paddybyers Running gdb gives me the exact same output reported in @gregferrell's comment above.

My brew --env is slightly different from Greg's:

CC: /usr/bin/llvm-gcc => /usr/llvm-gcc-4.2/bin/llvm-gcc-4.2
CXX: /usr/bin/llvm-g++ => /usr/llvm-gcc-4.2/bin/llvm-g++-4.2
LD: /usr/bin/llvm-gcc => /usr/llvm-gcc-4.2/bin/llvm-gcc-4.2
CFLAGS: -O3 -w -pipe -march=core2 -msse4
CXXFLAGS: -O3 -w -pipe -march=core2 -msse4
MAKEFLAGS: -j4

Here's a gist of the output I get from brew install node --force -v: https://gist.github.com/1482176

Alex Gorbatchev
gdb --args node build.js 
GNU gdb 6.3.50-20050815 (Apple version gdb-1708) (Mon Aug  8 20:32:45 UTC 2011)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "x86_64-apple-darwin"...Reading symbols for shared libraries ........... done

(gdb) run
Starting program: /Users/agorbatchev/.nvm/v0.6.6/bin/node build.js
Reading symbols for shared libraries ++++++++++.......................................................................................................................... done

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000948
0x0000000100055e05 in v8::HandleScope::RawClose () at node_crypto.h:166
166     return ss;
Alex Gorbatchev

v0.6.2 works fine...

Paddy Byers

Was there any new info on this?

v0.6.2 works fine...

I think that's because 0.6.2 had a hack that forced the stat struct to be bigger, but it turns out it wasn't a valid fix; only a hack that worked in some configurations.

I looked through the log that TrevorBurnham posted and I can't see what's wrong from that. I don't know if anyone else can reproduce it to investigate.

Just to reiterate, the key, it seems to me, is the mismatch between:

  • the compiler flags use for node_file.cc; and
  • the linker flags that determine which runtime version of the framework gets used.

Both seem to me from that log to be specifying x86_64, but Ben previously determined that the other flags - -D_LARGEFILE_SOURCE and/or -D_FILE_OFFSET_BITS=64 make a difference to the compiler, so what's the corresponding thing you need to tell the linker?

Nick Retallack

Well it works for me now. Perhaps it was broken with a particular version of Mac OS X Lion, and fixed when I installed some updates to the OS.

Aashay Desai

FWIW this happened to me today with Node 0.6.11 installed via nvm (aka compiled and installed from source, I'm not using the .pkg anymore because of the general lack of OpenSSL support).

Mac OS X Lion 10.7.3 (11D50b) on a 13" Late 2010 Macbook Air (1.86 GHz Intel Core 2 Duo, 4 GB 1067 MHz DDR3)

Relevant term output:

(gdb) run
Starting program: /Users/aashay/.nvm/v0.6.11/bin/node server.js
Reading symbols for shared libraries ++++++++++............................................................................................................................ done
The "sys" module is now called "util". It should have a similar interface.
Reading symbols for shared libraries . done
Reading symbols for shared libraries . done
Reading symbols for shared libraries . done
   info  - socket.io started
RedisClient authing
Intialized Socket.IO Redis node 1221086172
AnonyMouse 2 Server running in development mode @ http://localhost:4567

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: 13 at address: 0x0000000000000000
0x00000001000fce48 in v8::internal::Isolate::PromoteScheduledException () at node_crypto.h:166
166     return ss;
(gdb) backtrace
#0  0x00000001000fce48 in v8::internal::Isolate::PromoteScheduledException () at node_crypto.h:166
#1  0x0000000100072ead in v8::internal::Builtin_HandleApiCall () at node_crypto.h:166
Previous frame inner to this frame (gdb could not unwind past this frame)

otool -L which node

/Users/aashay/.nvm/v0.6.11/bin/node:
    /usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.5)
    /System/Library/Frameworks/Carbon.framework/Versions/A/Carbon (compatibility version 2.0.0, current version 153.0.0)
    /usr/lib/libssl.0.9.8.dylib (compatibility version 0.9.8, current version 44.0.0)
    /usr/lib/libcrypto.0.9.8.dylib (compatibility version 0.9.8, current version 44.0.0)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 159.1.0)
    /usr/lib/libutil.dylib (compatibility version 1.0.0, current version 1.0.0)
    /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 52.0.0)
    /System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices (compatibility version 1.0.0, current version 53.0.0)
    /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 635.19.0)
    /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices (compatibility version 1.0.0, current version 41.0.0)

gcc --version

i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2335.15.00)
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

file which node

/Users/aashay/.nvm/v0.6.11/bin/node: Mach-O 64-bit executable x86_64

disassemble uv_fs_stat

Dump of assembler code for function uv_fs_stat:
0x0000000100258160 <uv_fs_stat+0>:  push   %rbp
0x0000000100258161 <uv_fs_stat+1>:  mov    %rsp,%rbp
0x0000000100258164 <uv_fs_stat+4>:  sub    $0x50,%rsp
0x0000000100258168 <uv_fs_stat+8>:  mov    %rdx,%rax
0x000000010025816b <uv_fs_stat+11>: mov    %rdi,-0x8(%rbp)
0x000000010025816f <uv_fs_stat+15>: mov    %rsi,-0x10(%rbp)
0x0000000100258173 <uv_fs_stat+19>: mov    %rax,-0x18(%rbp)
0x0000000100258177 <uv_fs_stat+23>: mov    %rcx,-0x20(%rbp)
0x000000010025817b <uv_fs_stat+27>: mov    -0x8(%rbp),%rax
0x000000010025817f <uv_fs_stat+31>: mov    -0x10(%rbp),%rcx
0x0000000100258183 <uv_fs_stat+35>: mov    -0x18(%rbp),%rsi
0x0000000100258187 <uv_fs_stat+39>: mov    -0x20(%rbp),%rdi
0x000000010025818b <uv_fs_stat+43>: mov    $0x6,%r8d
0x0000000100258191 <uv_fs_stat+49>: mov    %rdi,-0x40(%rbp)
0x0000000100258195 <uv_fs_stat+53>: mov    %rax,%rdi
0x0000000100258198 <uv_fs_stat+56>: mov    %rsi,-0x48(%rbp)
0x000000010025819c <uv_fs_stat+60>: mov    %rcx,%rsi
0x000000010025819f <uv_fs_stat+63>: mov    %r8d,%edx
0x00000001002581a2 <uv_fs_stat+66>: mov    -0x48(%rbp),%rcx
0x00000001002581a6 <uv_fs_stat+70>: mov    -0x40(%rbp),%r8
0x00000001002581aa <uv_fs_stat+74>: callq  0x100256de0 <uv_fs_req_init>
0x00000001002581af <uv_fs_stat+79>: mov    -0x18(%rbp),%rax
0x00000001002581b3 <uv_fs_stat+83>: mov    %rax,%rdi
0x00000001002581b6 <uv_fs_stat+86>: callq  0x100287486 <dyld_stub_strdup>
0x00000001002581bb <uv_fs_stat+91>: mov    %rax,-0x30(%rbp)
0x00000001002581bf <uv_fs_stat+95>: mov    -0x18(%rbp),%rax
0x00000001002581c3 <uv_fs_stat+99>: mov    %rax,%rdi
0x00000001002581c6 <uv_fs_stat+102>:    callq  0x100287498 <dyld_stub_strlen>
0x00000001002581cb <uv_fs_stat+107>:    mov    %eax,-0x34(%rbp)
0x00000001002581ce <uv_fs_stat+110>:    mov    -0x34(%rbp),%eax
0x00000001002581d1 <uv_fs_stat+113>:    cmp    $0x0,%eax
0x00000001002581d4 <uv_fs_stat+116>:    jle    0x1002581fb <uv_fs_stat+155>
0x00000001002581d6 <uv_fs_stat+118>:    mov    -0x34(%rbp),%eax
0x00000001002581d9 <uv_fs_stat+121>:    sub    $0x1,%eax
0x00000001002581dc <uv_fs_stat+124>:    mov    -0x18(%rbp),%rcx
0x00000001002581e0 <uv_fs_stat+128>:    movslq %eax,%rax
0x00000001002581e3 <uv_fs_stat+131>:    mov    (%rcx,%rax,1),%al
0x00000001002581e6 <uv_fs_stat+134>:    cmp    $0x5c,%al
0x00000001002581e8 <uv_fs_stat+136>:    jne    0x1002581fb <uv_fs_stat+155>
0x00000001002581ea <uv_fs_stat+138>:    mov    -0x34(%rbp),%eax
0x00000001002581ed <uv_fs_stat+141>:    sub    $0x1,%eax
0x00000001002581f0 <uv_fs_stat+144>:    mov    -0x30(%rbp),%rcx
0x00000001002581f4 <uv_fs_stat+148>:    movslq %eax,%rax
0x00000001002581f7 <uv_fs_stat+151>:    movb   $0x0,(%rcx,%rax,1)
0x00000001002581fb <uv_fs_stat+155>:    mov    -0x20(%rbp),%rax
0x00000001002581ff <uv_fs_stat+159>:    cmp    $0x0,%rax
0x0000000100258203 <uv_fs_stat+163>:    je     0x10025828e <uv_fs_stat+302>
0x0000000100258209 <uv_fs_stat+169>:    mov    -0x8(%rbp),%rax
0x000000010025820d <uv_fs_stat+173>:    mov    %rax,%rdi
0x0000000100258210 <uv_fs_stat+176>:    callq  0x1002552c0 <uv_ref>
0x0000000100258215 <uv_fs_stat+181>:    mov    -0x30(%rbp),%rax
0x0000000100258219 <uv_fs_stat+185>:    mov    -0x10(%rbp),%rcx
0x000000010025821d <uv_fs_stat+189>:    mov    $0x0,%edx
0x0000000100258222 <uv_fs_stat+194>:    lea    -0x1279(%rip),%rdi        # 0x100256fb0 <uv__fs_after>
0x0000000100258229 <uv_fs_stat+201>:    mov    %rdi,-0x50(%rbp)
0x000000010025822d <uv_fs_stat+205>:    mov    %rax,%rdi
0x0000000100258230 <uv_fs_stat+208>:    mov    %edx,%esi
0x0000000100258232 <uv_fs_stat+210>:    mov    -0x50(%rbp),%rdx
0x0000000100258236 <uv_fs_stat+214>:    callq  0x1002742a0 <eio_stat>
0x000000010025823b <uv_fs_stat+219>:    mov    -0x10(%rbp),%rcx
0x000000010025823f <uv_fs_stat+223>:    mov    %rax,0xd8(%rcx)
0x0000000100258246 <uv_fs_stat+230>:    mov    -0x30(%rbp),%rax
0x000000010025824a <uv_fs_stat+234>:    mov    %rax,%rdi
0x000000010025824d <uv_fs_stat+237>:    callq  0x1002870d8 <dyld_stub_free>
0x0000000100258252 <uv_fs_stat+242>:    mov    -0x10(%rbp),%rax
0x0000000100258256 <uv_fs_stat+246>:    mov    0xd8(%rax),%rax
0x000000010025825d <uv_fs_stat+253>:    cmp    $0x0,%rax
0x0000000100258261 <uv_fs_stat+257>:    jne    0x100258282 <uv_fs_stat+290>
0x0000000100258263 <uv_fs_stat+259>:    mov    -0x8(%rbp),%rax
0x0000000100258267 <uv_fs_stat+263>:    mov    $0xc,%ecx
0x000000010025826c <uv_fs_stat+268>:    mov    %rax,%rdi
0x000000010025826f <uv_fs_stat+271>:    mov    %ecx,%esi
0x0000000100258271 <uv_fs_stat+273>:    callq  0x100264580 <uv__set_sys_error>
0x0000000100258276 <uv_fs_stat+278>:    movl   $0xffffffff,-0x28(%rbp)
0x000000010025827d <uv_fs_stat+285>:    jmpq   0x100258317 <uv_fs_stat+439>
0x0000000100258282 <uv_fs_stat+290>:    movl   $0x0,-0x28(%rbp)
0x0000000100258289 <uv_fs_stat+297>:    jmpq   0x100258317 <uv_fs_stat+439>
0x000000010025828e <uv_fs_stat+302>:    mov    -0x10(%rbp),%rax
0x0000000100258292 <uv_fs_stat+306>:    mov    $0x48,%rcx
0x000000010025829c <uv_fs_stat+316>:    add    %rcx,%rax
0x000000010025829f <uv_fs_stat+319>:    mov    -0x30(%rbp),%rcx
0x00000001002582a3 <uv_fs_stat+323>:    mov    %rcx,%rdi
0x00000001002582a6 <uv_fs_stat+326>:    mov    %rax,%rsi
0x00000001002582a9 <uv_fs_stat+329>:    callq  0x100287468 <dyld_stub_stat$INODE64>
0x00000001002582ae <uv_fs_stat+334>:    mov    %eax,%ecx
0x00000001002582b0 <uv_fs_stat+336>:    movslq %ecx,%rcx
0x00000001002582b3 <uv_fs_stat+339>:    mov    -0x10(%rbp),%rdx
0x00000001002582b7 <uv_fs_stat+343>:    mov    %rcx,0x28(%rdx)
0x00000001002582bb <uv_fs_stat+347>:    mov    -0x30(%rbp),%rcx
0x00000001002582bf <uv_fs_stat+351>:    mov    %rcx,%rdi
0x00000001002582c2 <uv_fs_stat+354>:    callq  0x1002870d8 <dyld_stub_free>
0x00000001002582c7 <uv_fs_stat+359>:    mov    -0x10(%rbp),%rax
0x00000001002582cb <uv_fs_stat+363>:    mov    0x28(%rax),%rax
0x00000001002582cf <uv_fs_stat+367>:    cmp    $0x0,%rax
0x00000001002582d3 <uv_fs_stat+371>:    jge    0x1002582f3 <uv_fs_stat+403>
0x00000001002582d5 <uv_fs_stat+373>:    callq  0x100286f52 <dyld_stub___error>
0x00000001002582da <uv_fs_stat+378>:    mov    (%rax),%eax
0x00000001002582dc <uv_fs_stat+380>:    mov    -0x8(%rbp),%rcx
0x00000001002582e0 <uv_fs_stat+384>:    mov    %rcx,%rdi
0x00000001002582e3 <uv_fs_stat+387>:    mov    %eax,%esi
0x00000001002582e5 <uv_fs_stat+389>:    callq  0x100264580 <uv__set_sys_error>
0x00000001002582ea <uv_fs_stat+394>:    movl   $0xffffffff,-0x28(%rbp)
0x00000001002582f1 <uv_fs_stat+401>:    jmp    0x100258317 <uv_fs_stat+439>
0x00000001002582f3 <uv_fs_stat+403>:    mov    -0x10(%rbp),%rax
0x00000001002582f7 <uv_fs_stat+407>:    mov    $0x48,%rcx
0x0000000100258301 <uv_fs_stat+417>:    add    %rcx,%rax
0x0000000100258304 <uv_fs_stat+420>:    mov    -0x10(%rbp),%rcx
0x0000000100258308 <uv_fs_stat+424>:    mov    %rax,0x30(%rcx)
0x000000010025830c <uv_fs_stat+428>:    mov    -0x10(%rbp),%rax
0x0000000100258310 <uv_fs_stat+432>:    mov    0x28(%rax),%rax
0x0000000100258314 <uv_fs_stat+436>:    mov    %eax,-0x28(%rbp)
0x0000000100258317 <uv_fs_stat+439>:    mov    -0x28(%rbp),%eax
0x000000010025831a <uv_fs_stat+442>:    mov    %eax,-0x24(%rbp)
0x000000010025831d <uv_fs_stat+445>:    mov    -0x24(%rbp),%eax
0x0000000100258320 <uv_fs_stat+448>:    add    $0x50,%rsp
0x0000000100258324 <uv_fs_stat+452>:    pop    %rbp
0x0000000100258325 <uv_fs_stat+453>:    retq   
End of assembler dump.
Ben Noordhuis

@aashay: Looks like it could be related to #2498. Your script seems to be loading add-ons. Does the crash also happen with an empty script?

Aashay Desai

Interestingly enough, no. I managed to load the basic hello world server just fine.

Ben Noordhuis

@aashay: Maybe one of those add-ons is stamping over memory. Might be worth reporting to their maintainers.

Jason Connell

ry's patch worked for me. mac osx 10.6.8 intel core 2 duo.

i just recently pulled down 0.6.11 on CentOS 5.5, compiled and ran fine.

Alex Gorbatchev

v0.6.13 and it's still happening...

Ben Noordhuis bnoordhuis closed this March 20, 2012
Ben Noordhuis

I'm going to close this issue unless someone can confirm that it still happens with non-homebrew builds (i.e. built straight from the repo). I'm pretty sure it's something in homebrew's setup because our .pkg doesn't have this issue.

Trevor Burnham

Please reopen. I ran brew unlink node, then did an old-fashioned install:

curl http://nodejs.org/dist/node-v0.6.13.tar.gz | tar xz --strip-components=1
./configure --prefix=/usr/local --without-npm
make install

Same issue. It's not Homebrew-specific. I tried again without the --without-npm flag and with --prefix set to an empty directory; same result.

The Mac .pkg installer, on the other hand, works perfectly. So the issue isn't "What's Homebrew doing wrong?" It's "What's the .pkg installer doing right?"

Ben Noordhuis bnoordhuis reopened this March 21, 2012
Ben Noordhuis

Reopened.

The Mac .pkg installer, on the other hand, works perfectly. So the issue isn't "What's Homebrew doing wrong?" It's "What's the .pkg installer doing right?"

I think an even better question is "what compiler are you using?" and "what does file out/Release/node print?" :-)

Trevor Burnham

what compiler are you using?

gcc 4.2.1, as installed by XCode

what does file out/Release/node print?

out/Release/node: Mach-O 64-bit executable x86_64

No surprises; most other folks in this thread have reported the same.

Trevor Burnham

Here's what gdb gives me when I try to run npm with the node binary installed from source: https://gist.github.com/2147093

Same as reported by @gregferrell and @aashay above. I'm on a Core i7; @gregferrell and @aashay said they were on a Core 2 Duo.

Greg Ferrell

I'll be honest, I moved to using the packages because brew never could install it correctly for me even after the updates since i first posted this. Ill try to make from source tonight and see if i still get the same errors.

Alex Gorbatchev
nvm install v0.6.13

segfaults going all the way back until v0.6.2 which works

osx package v0.6.13 installer works, as does nvm installing 0.7.6

Denny Trebbin

```brew --env
CC: /usr/bin/clang
CXX: /usr/bin/clang++ => /usr/bin/clang
LD: /usr/bin/clang
CFLAGS: -Os -w -pipe -march=native -Qunused-arguments
CXXFLAGS: -Os -w -pipe -march=native -Qunused-arguments
MAKEFLAGS: -j4

no problems on my machine.
ages ago i experienced the same issue but i figured out for me that not upgrading xcode correctly causes some strange compiling/linking errors.
Ben Noordhuis

Can someone who is seeing this problem with the master branch try out the patch below?

diff --git a/common.gypi b/common.gypi
index 6e13b60..7f5baab 100644
--- a/common.gypi
+++ b/common.gypi
@@ -149,6 +149,7 @@
         ],
       }],
       ['OS=="mac"', {
+        'defines': ['_DARWIN_USE_64_BIT_INODE=1'],
         'xcode_settings': {
           'ALWAYS_SEARCH_USER_PATHS': 'NO',
           'GCC_CW_ASM_SYNTAX': 'NO',                # No -fasm-blocks

Same patch but for v0.6.x:

diff --git a/deps/uv/config-unix.mk b/deps/uv/config-unix.mk
index 8fe7254..ca1b145 100644
--- a/deps/uv/config-unix.mk
+++ b/deps/uv/config-unix.mk
@@ -50,7 +50,7 @@ endif
 ifeq (Darwin,$(uname_S))
 EV_CONFIG=config_darwin.h
 EIO_CONFIG=config_darwin.h
-CPPFLAGS += -Isrc/ares/config_darwin
+CPPFLAGS += -D_DARWIN_USE_64_BIT_INODE=1 -Isrc/ares/config_darwin
 LINKFLAGS+=-framework CoreServices
 OBJS += src/unix/darwin.o
 OBJS += src/unix/kqueue.o
diff --git a/wscript b/wscript
index 2b04358..a63db7d 100644
--- a/wscript
+++ b/wscript
@@ -469,6 +469,9 @@ def configure(conf):
   conf.env.append_value('CPPFLAGS',  '-D_LARGEFILE_SOURCE')
   conf.env.append_value('CPPFLAGS',  '-D_FILE_OFFSET_BITS=64')

+  if sys.platform.startswith('darwin'):
+    conf.env.append_value('CPPFLAGS', '-D_DARWIN_USE_64_BIT_INODE=1')
+
   # Makes select on windows support more than 64 FDs
   if sys.platform.startswith("win32"):
     conf.env.append_value('CPPFLAGS', '-DFD_SETSIZE=1024');
Trevor Burnham

@bnoordhuis Tried applying the latter patch to the v0.6 branch by saving it as patch.diff and running

patch -p1 < patch.diff

but got

patching file deps/uv/config-unix.mk
patching file wscript
patch unexpectedly ends in middle of line
Hunk #1 succeeded at 469 with fuzz 1.

(Applying the patch to the v0.6.14-release branch produces the same outcome.) Am I applying it incorrectly, or is there a problem with the patch?

Ben Noordhuis bnoordhuis referenced this issue from a commit April 02, 2012
Commit has since been removed from the repository and is no longer available.
Ben Noordhuis

It should apply cleanly, just tested it with git apply. Here is the patch as a commit against v0.6.14: bnoordhuis/node@1a214df

Trevor Burnham

Seems to work! I was able to install from that commit and run npm, etc. with no problems.

Ben Noordhuis bnoordhuis closed this issue from a commit April 02, 2012
Ben Noordhuis build: define _DARWIN_USE_64_BIT_INODE=1 on OS X
Fixes a segmentation fault on some OS X systems due to sizeof(struct stat)
mismatches.

Fixes #2061.
ffee873
Ben Noordhuis bnoordhuis closed this in ffee873 April 02, 2012
Ben Noordhuis

Thanks @TrevorBurnham. Fixed in ffee873 and 92c0c69.

Sambasiva Suda ssuda referenced this issue from a commit in ssuda/node April 02, 2012
Ben Noordhuis build: define _DARWIN_USE_64_BIT_INODE=1 on OS X
Fixes a segmentation fault on some OS X systems due to sizeof(struct stat)
mismatches.

Fixes #2061.
92c0c69
Isaac Z. Schlueter isaacs referenced this issue from a commit April 07, 2012
Commit has since been removed from the repository and is no longer available.
Isaac Z. Schlueter isaacs referenced this issue from a commit April 08, 2012
Commit has since been removed from the repository and is no longer available.
Isaac Z. Schlueter isaacs referenced this issue from a commit in isaacs/node April 07, 2012
Isaac Z. Schlueter 2012.04.09 Version 0.6.15 (stable)
* Update npm to 1.1.16

* Show licenses in binary installers.

* unix: add uv_fs_read64, uv_fs_write64 and uv_fs_ftruncate64 (Ben Noordhuis)

* add 64bit offset fs functions (Igor Zinkovsky)

* windows: don't report ENOTSOCK when attempting to bind an udp handle twice (Bert Belder)

* windows: backport pipe-connect-to-file fixes from master (Bert Belder)

* windows: never call fs event callbacks after closing the watcher (Bert Belder)

* fs.readFile: don't make the callback before the fd is closed (Bert Belder)

* windows: use 64bit offsets for uv_fs apis (Igor Zinkovsky)

* Fix #2061: segmentation fault on OS X due to stat size mismatch (Ben Noordhuis)
f160a45
Karl Skomski Skomski referenced this issue from a commit April 13, 2012
Commit has since been removed from the repository and is no longer available.
Erik Dubbelboer ErikDubbelboer referenced this issue from a commit April 02, 2012
Ben Noordhuis build: define _DARWIN_USE_64_BIT_INODE=1 on OS X
Fixes a segmentation fault on some OS X systems due to sizeof(struct stat)
mismatches.

Fixes #2061.
7ef208b
Vincent Battaglia
vinch commented May 09, 2012

Still have the same "Segmentation fault: 11" error with Node 0.6.17. Tried to install with homebrew, .pkg file and by compiling. No luck. I'm thinking about reformatting my computer unless someone can help.

Vincent Battaglia
vinch commented May 09, 2012

Also. I don't think the problem is related because I don't have it every time. Only with one app actually. And not always. Sometimes, I just need to run "node app.js" multiple times until it works... Sometimes it works after 3 tries, sometimes after 10... Does someone had this problem already?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.