Skip to content
This repository has been archived by the owner on Apr 22, 2023. It is now read-only.

segfault in v0.6.7 on osx lion (possibly in a node_crypto.cc thread pool call?) #2498

Closed
ry opened this issue Jan 9, 2012 · 25 comments
Closed
Assignees

Comments

@ry
Copy link

ry commented Jan 9, 2012

reported by @derekcollison

~> node -v
v0.6.7
~> which node
/usr/local/bin/node
~> npm
Segmentation fault: 11
~> which npm
/usr/local/bin/npm
~> gdb --args node `which npm` -v
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) r
Starting program: /usr/local/bin/node /usr/local/bin/npm -v
Reading symbols for shared libraries ++++++++++.......................................................................................................................... done

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000950
0x00000001000570e5 in v8::HandleScope::RawClose () at node_crypto.h:166
166     return ss;
(gdb) where
#0  0x00000001000570e5 in v8::HandleScope::RawClose () at node_crypto.h:166
#1  0x0000000100011597 in v8::HandleScope::Close<v8::Object> () at /Users/derek/Downloads/node-v0.6.7/deps/v8/include/v8.h:3953
#2  0x0000000100011597 in Stat (args=@0x7fff5fbff288) at v8.h:343
#3  0x0000000100072f8e in v8::internal::Builtin_HandleApiCall () at node_crypto.h:166
Previous frame inner to this frame (gdb could not unwind past this frame)
(gdb) 
@derekcollison
Copy link

> uname -a
Darwin Dereks-iMac.local 11.2.0 Darwin Kernel Version 11.2.0: Tue Aug 9 20:54:00 PDT 2011; root:xnu-1699.24.8
1/RELEASE_X86_64 x86_64
>
> gcc -v
Using built-in specs.
Target: i686-apple-darwin11
Configured with: /private/var/tmp/llvmgcc42/llvmgcc42-2335.15
25/src/configure --disable-checking --enable-werror --prefix=/Developer/usr/llvm-gcc-4.2 --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-prefix=llvm- --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ --with-slibdir=/usr/lib --build=i686-apple-darwin11 --enable-llvm=/private/var/tmp/llvmgcc42/llvmgcc42-2335.15
25/dst-llvmCore/Developer/usr/local --program-prefix=i686-apple-darwin11- --host=x86_64-apple-darwin11 --target=i686-apple-darwin11 --with-gxx-include-dir=/usr/include/c++/4.2.1
Thread model: posix
gcc version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2335.15.00)
~>
~> gdb -v
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".

@derekcollison
Copy link

I am going to completely blow away Xcode and reinstall..

@bnoordhuis
Copy link
Member

@derekcollison: If the crash keeps happening, can you send me your node binary and a core file from the crash? ulimit -c unlimited turns on core dumps.

@derekcollison
Copy link

Sure, it seems to be npm that is causing it. Vagrind didn't offer much insight..

I blew away all of Xcode and reinstalled, same thing happens..

On Jan 10, 2012, at 8:49 AM, Ben [email protected] wrote:

@derekcollison: If the crash keeps happening, can you send me your node binary and a core file from the crash? ulimit -c unlimited turns on core dumps.


Reply to this email directly or view it on GitHub:
#2498 (comment)

@derekcollison
Copy link

Ben,

Still fairly certain it is my messed up machine, however I uploaded the core from npm -v, along with the node and npm files. You can find them here..

http://dl.dropbox.com/u/7891/NodeIssue/node
http://dl.dropbox.com/u/7891/NodeIssue/npm
http://dl.dropbox.com/u/7891/NodeIssue/core.npm-v.bz2

@davidbanham
Copy link

I'm seeing the same behaviour. Node v0.6.8 compiled with the --debug flag

davidbanham@David-Banhams-MacBook-Pro:~/repos/hnymn$ /opt/node/bin/node -v
v0.6.8
davidbanham@David-Banhams-MacBook-Pro:
/repos/hnymn$

davidbanham@David-Banhams-MacBook-Pro:~/repos/hnymn$ gdb --args ~/opt/node/bin/node app.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: /Users/davidbanham/opt/node/bin/node app.js
Reading symbols for shared libraries ++++++++++.......................................................................................................................... done
Reading symbols for shared libraries . done

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x0000007fff5fc00a
0x00000001000fca48 in v8::internal::Isolate::PromoteScheduledException () at node_crypto.h:166
166 return ss;
(gdb)

@davidbanham
Copy link

(gdb) backtrace full
#0 0x00000001000fca48 in v8::internal::Isolate::PromoteScheduledException () at node_crypto.h:166
No symbol table info available.
#1 0x0000000100072aed in v8::internal::Builtin_HandleApiCall () at node_crypto.h:166
No symbol table info available.
Previous frame inner to this frame (gdb could not unwind past this frame)
(gdb)

@davidbanham
Copy link

davidbanham@David-Banhams-MacBook-Pro:/repos/hnymn$ gcc -v
Using built-in specs.
Target: i686-apple-darwin11
Configured with: /private/var/tmp/llvmgcc42/llvmgcc42-2335.15
25/src/configure --disable-checking --enable-werror --prefix=/Developer/usr/llvm-gcc-4.2 --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-prefix=llvm- --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ --with-slibdir=/usr/lib --build=i686-apple-darwin11 --enable-llvm=/private/var/tmp/llvmgcc42/llvmgcc42-2335.1525/dst-llvmCore/Developer/usr/local --program-prefix=i686-apple-darwin11- --host=x86_64-apple-darwin11 --target=i686-apple-darwin11 --with-gxx-include-dir=/usr/include/c++/4.2.1
Thread model: posix
gcc version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2335.15.00)
davidbanham@David-Banhams-MacBook-Pro:
/repos/hnymn$ gdb -v
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".

@bnoordhuis
Copy link
Member

@derekcollison, @davidbanham: Sorry for the delay. Does it still happen with recent releases?

@derekcollison
Copy link

I will check and get back to you..

On Feb 17, 2012, at 6:33 PM, Ben [email protected] wrote:

@derekcollison, @davidbanham: Sorry for the delay. Does it still happen with recent releases?


Reply to this email directly or view it on GitHub:
#2498 (comment)

@derekcollison
Copy link

I just installed 0.6.11 and it still happens..

I then install 0.7.4, and that works, no segfault.

I will try to remove Xcode again and go with the newly released command
line tools only to see if it makes a difference..

On Fri, Feb 17, 2012 at 6:33 PM, Ben Noordhuis <
[email protected]

wrote:

@derekcollison, @davidbanham: Sorry for the delay. Does it still happen
with recent releases?


Reply to this email directly or view it on GitHub:
#2498 (comment)

@derekcollison
Copy link

Still happens on the 0.6.11 series when using the new command line tools..

/> gcc -v
Using built-in specs.
Target: i686-apple-darwin11
Configured with: /private/var/tmp/llvmgcc42/llvmgcc42-2336.9
22/src/configure --disable-checking --enable-werror --prefix=/Applications/Xcode.app/Contents/Developer/usr/llvm-gcc-4.2 --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-prefix=llvm- --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ --with-slibdir=/usr/lib --build=i686-apple-darwin11 --enable-llvm=/private/var/tmp/llvmgcc42/llvmgcc42-2336.9~22/dst-llvmCore/Developer/usr/local --program-prefix=i686-apple-darwin11- --host=x86_64-apple-darwin11 --target=i686-apple-darwin11 --with-gxx-include-dir=/usr/include/c++/4.2.1
Thread model: posix
gcc version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.9.00)
~/> cc -v
Apple clang version 3.1 (tags/Apple/clang-318.0.45) (based on LLVM 3.1svn)
Target: x86_64-apple-darwin11.3.0
Thread model: posix

@bnoordhuis
Copy link
Member

@derekcollison: Thanks. Can you post the output of file out/Release/node for both versions? I'm curious if they're built for different architectures.

@derekcollison
Copy link

~/.nvm/v0.6.11/bin> file node
node: Mach-O 64-bit executable x86_64
~/.nvm/v0.6.11/bin> cd ~/.nvm/v0.6.11/bin
~/.nvm/v0.6.11/bin> file node
node: Mach-O 64-bit executable x86_64

@bnoordhuis
Copy link
Member

@derekcollison: Are you running file twice on the same binary or am I misreading that?

@derekcollison
Copy link

I changed directories..

On Feb 21, 2012, at 7:17 AM, Ben [email protected] wrote:

@derekcollison: Are you running file twice on the same binary or am I misreading that?


Reply to this email directly or view it on GitHub:
#2498 (comment)

@bnoordhuis
Copy link
Member

Yes, but the path in your prompt doesn't appear to change.

@derekcollison
Copy link

I removed full path, but it's two different binaries..

On Feb 21, 2012, at 7:35 AM, Ben [email protected] wrote:

Yes, but the path in your prompt doesn't appear to change.


Reply to this email directly or view it on GitHub:
#2498 (comment)

@datapimp
Copy link

I am getting a segault as well, when trying to run npm that shipped with the downloaded version of node 0.6.11

thinktank ➜  bin git:(master) file node
node: Mach-O 64-bit executable x86_64
thinktank ➜  bin git:(master) gcc -v

Using built-in specs.
Target: i686-apple-darwin11
Configured with: /private/var/tmp/llvmgcc42/llvmgcc42-2336.1~22/src/configure --disable-checking --enable-werror --prefix=/Developer/usr/llvm-gcc-4.2 --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-prefix=llvm- --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ --with-slibdir=/usr/lib --build=i686-apple-darwin11 --enable-llvm=/private/var/tmp/llvmgcc42/llvmgcc42-2336.1~22/dst-llvmCore/Developer/usr/local --program-prefix=i686-apple-darwin11- --host=x86_64-apple-darwin11 --target=i686-apple-darwin11 --with-gxx-include-dir=/usr/include/c++/4.2.1
Thread model: posix
gcc version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.1.00)

Here is what I get from gdb

Starting program: /Users/jonathan/Developer/bin/node npm-cli.js
Reading symbols for shared libraries . done

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000950
0x0000000100057765 in v8::HandleScope::RawClose () at node_crypto.h:166
166     return ss;
(gdb) backtrace
#0  0x0000000100057765 in v8::HandleScope::RawClose () at node_crypto.h:166
#1  0x00000001000110f7 in v8::HandleScope::Close<v8::Object> () at /Users/jonathan/Downloads/node-v0.6.11/deps/v8/include/v8.h:3953
#2  0x00000001000110f7 in Stat (args=@0x7fff5fbfe978) at v8.h:343
#3  0x000000010007360e in v8::internal::Builtin_HandleApiCall () at node_crypto.h:166

@davidbanham
Copy link

Sorry for the delay in responding, still seeing the issue in v0.6.12

davidbanham@David-Banhams-MacBook-Pro:$ gdb --args node server.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: /Users/davidbanham/dotfiles/nvm/v0.6.12/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
info: Running as DEV server

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

@novemberborn
Copy link

@davidbanham I ran into similar issues, and then it turned out somewhere in a node_modules an old hiredis had survived, which was built for Node 0.4.x. Could you possibly have run into a similar issue?

@saimonmoore
Copy link

I'm still seeing this issue in 0.6.14 (checked out from git and compiled manually):

saimon@artemis node$ node -v
v0.6.14
saimon@artemis node$ which node
/usr/local/bin/node
saimon@artemis node$ npm
Segmentation fault: 11
saimon@artemis node$ which npm
/usr/local/bin/npm

saimon@artemis node$ node test/simple/test-console.js 
Segmentation fault: 11
saimon@artemis noderuby-1.8.7-p249((v0.6.14)) $ gdb --args node `which npm` -v
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) r
Starting program: /private/tmp/node/node /usr/local/bin/npm -v
Reading symbols for shared libraries ++++++++++............................................................................................................................ done

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


saimon@artemis node$ uname -a
Darwin artemis.local 11.3.0 Darwin Kernel Version 11.3.0: Thu Jan 12 18:47:41 PST 2012; root:xnu-1699.24.23~1/RELEASE_X86_64 x86_64
saimon@artemis node$ gcc -v
Using built-in specs.
Target: i686-apple-darwin11
Configured with: /private/var/tmp/llvmgcc42/llvmgcc42-2335.15~25/src/configure --disable-checking --enable-werror --prefix=/Developer/usr/llvm-gcc-4.2 --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-prefix=llvm- --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ --with-slibdir=/usr/lib --build=i686-apple-darwin11 --enable-llvm=/private/var/tmp/llvmgcc42/llvmgcc42-2335.15~25/dst-llvmCore/Developer/usr/local --program-prefix=i686-apple-darwin11- --host=x86_64-apple-darwin11 --target=i686-apple-darwin11 --with-gxx-include-dir=/usr/include/c++/4.2.1
Thread model: posix
gcc version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2335.15.00)
saimon@artemis node$ gdb -v
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".

saimon@artemis node$ file node
node: Mach-O 64-bit executable x86_64

This is blocking me from using node :(

@saimonmoore
Copy link

I applied ry's patch from here: #2061 (comment)

and it's working now...

@ghost ghost assigned bnoordhuis Mar 28, 2012
@derekcollison
Copy link

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

#2061 (comment)

On Wed, Mar 28, 2012 at 6:45 AM, Saimon Moore <
[email protected]

wrote:

I applied ry's patch from here:
#2061 (comment)

and it's working now...


Reply to this email directly or view it on GitHub:
#2498 (comment)

@derekcollison
Copy link

This worked for me as well..

richardlau pushed a commit to ibmruntimes/node that referenced this issue Oct 18, 2016
This reverts commit c86c1ee.

original commit message:

    This patch

     1. moves the basic validation of arguments to `truncate` family
        of functions to the JavaScript layer from the C++ layer.

     2. makes sure that the File Descriptors are validated strictly.

    PR-URL: nodejs#2498
    Reviewed-By: Trevor Norris <[email protected]>

PR-URL: nodejs/node#7950
Reviewed-By: Julien Gilli <[email protected]>
Reviewed-By: Rod Vagg <[email protected]>
Reviewed-By: Minwoo Jung <[email protected]>
Reviewed-By: James M Snell <[email protected]>
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

7 participants