This repository has been archived by the owner on Apr 22, 2023. It is now read-only.
v0.6.0 Segmentation fault: 11 on OS X 10.7.2 via homebrew install #2061
Milestone
Comments
|
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 ? |
|
Please open it in gdb and provide a stacktrace |
Got lots of warnings on the intial before hitting run and backtrace so long list |
|
Also, i just did a make install node from source and get the same errors. |
|
What version of GCC? |
|
I can't repeat. Strange bug. @DTrejo is also seeing this same problem. |
|
Please give the output of |
|
|
@mraleph found this https://gist.github.com/1352731 We think it's related to What CPU do you have? |
|
2.8ghz core 2 duo on a 2009 unibody 15" MBP On Nov 9, 2011, at 15:45, Ryan [email protected] wrote:
|
|
Is the node binary 32 bit or 64? |
|
/usr/local/bin/node: Mach-O 64-bit executable x86_64 |
|
Please show the assembly for On my (working) binary it is |
$ 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) |
|
Also experiencing this exact issue for what it's worth. Almost identical setup except on a 2007 2.4ghz core 2 duo 24" iMac. |
|
Also getting this issue on Snow Leopard 10.6.8 with node built from source and from homebrew. gcc -v: |
|
can someone please provide me a login onto a box experiencing this issue? |
|
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. |
|
Maybe chime in over here too (Homebrew/legacy-homebrew#8460) Manual builds as well as I'll give @ry access to my machine again over the coming days to help trace this. |
|
Adding some more info to the mix. |
|
Getting the same segmentation fault with 0.6.1 built from source. |
|
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 |
|
@ry got the same issue as above, but .pkg worked for me |
|
v0.6.1 .pkg working fine here! |
|
Managed to install npm now with the 0.6.1.pkg file, will build from source as well and report. (Snow Leopard) |
|
pkg file works! Thanks Ryan! Do we need to test a different way to help diagnose? |
|
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 :( |
|
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. |
|
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? |
|
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: otool -L gcc --version file disassemble uv_fs_stat |
|
Interestingly enough, no. I managed to load the basic hello world server just fine. |
|
@aashay: Maybe one of those add-ons is stamping over memory. Might be worth reporting to their maintainers. |
|
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. |
|
v0.6.13 and it's still happening... |
|
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. |
|
Please reopen. I ran Same issue. It's not Homebrew-specific. I tried again without the 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?" |
|
Reopened.
I think an even better question is "what compiler are you using?" and "what does |
gcc 4.2.1, as installed by XCode
No surprises; most other folks in this thread have reported the same. |
|
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. |
|
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. |
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 |
no problems on my machine. |
|
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-blocksSame 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'); |
|
@bnoordhuis Tried applying the latter patch to the but got (Applying the patch to the |
|
It should apply cleanly, just tested it with |
|
Seems to work! I was able to install from that commit and run npm, etc. with no problems. |
|
Thanks @TrevorBurnham. Fixed in ffee873 and 92c0c69. |
ssuda
pushed a commit
to ssuda/node
that referenced
this issue
Apr 3, 2012
Fixes a segmentation fault on some OS X systems due to sizeof(struct stat) mismatches. Fixes nodejs#2061.
isaacs
added a commit
to isaacs/node-v0.x-archive
that referenced
this issue
Apr 9, 2012
* 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 nodejs#2061: segmentation fault on OS X due to stat size mismatch (Ben Noordhuis)
|
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. |
|
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 subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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?
The text was updated successfully, but these errors were encountered: