Segmentation fault

[kmentch]

I was playing tonight trying to get something working with an update version of node, and it seems I have broken something in npm or theres an issue with node. Whenever I run anything I get a segmentation fault.

npm -v
1.2.2
[1] 25761 segmentation fault npm -v

No matter what the command is the last line of output is the segmentation fault. I am also unable to get a node app running, I was attempting to clean the cache with (npm cache clean) but that throws the same segmentation fault error.

npm cache clean
[1] 26075 segmentation fault npm cache clean

I tried uninstalling npm/node completely and re-installing from all from homebrew however that has not resolved anything.

I tried doing an npm install of an app and here is what the results were:

Not building native library for cygwin
CXX(target) Release/obj.target/contextify/src/contextify.o
SOLINK_MODULE(target) Release/contextify.node
SOLINK_MODULE(target) Release/contextify.node: Finished
/usr/local/Cellar/node/0.8.18/lib/node_modules/npm/bin/node-gyp-bin/node-gyp: line 2: 74366 Segmentation fault: 11 node "dirname "$0"/../../node_modules/node-gyp/bin/node-gyp.js" "$@"
npm WARN optional dep failed, continuing contextify@0.1.6

Node -v : 0.8.18 (yes I know its an old version) - same issue happens with most recent version too
Npm -v : 1.2.2

Also note that I am running OS X (10.9) Mavericks
Any help would be awesome.

[indutny]

Hi!

Thanks for reporting this to us.

Can you please try running something like this : lldb -- node which npm -v? Once you'll start it - command prompt will be opened and you should type "run" (followed by return key), and, when it'll crash, "bt" (followed by return key too).

Thank you again!

[kmentch]

Here is the output:

Current executable set to 'node' (x86_64).
(lldb) run
Process 74637 launched: '/usr/local/bin/node' (x86_64)
1.2.2
Process 74637 stopped

• thread Writing to files in loops seems to be capped at 250 file.write calls. #1: tid = 0x17ebf, 0x0000000100277236 nodev8::internal::MemoryAllocator::Free(v8::internal::MemoryChunk*) + 64, queue = 'com.apple.main-thread, stop reason = EXC_BAD_ACCESS (code=1, address=0x10) frame #0: 0x0000000100277236 nodev8::internal::MemoryAllocator::Free(v8::internal::MemoryChunk_) + 64
  node`v8::internal::MemoryAllocator::Free(v8::internal::MemoryChunk_) + 64:
  -> 0x100277236: movb 13(%rax), %cl
  0x100277239: movl $1, %esi
  0x10027723e: shll %cl, %esi
  0x100277240: movq 16(%rbx), %rcx

[indutny]

/cc @tjfontaine .

[tjfontaine]

yes, @indutny this is what I was seeing as well, it's odd that it's happening on 0.8.18 though as I was expecting the v8 upgrade to be the culprit, I'm not sure what to tell you @kmentch it's difficult to track down what's happening, but essentially node is exiting cleanly and while v8 is cleaning up after itself it's more or less double-free'ing

[indutny]

So it still fails for you too @tjfontaine ?

[tjfontaine]

yes v0.8 has been failing on 10.8+ for me with my clang toolchain, I haven't really tested with the llvm-gcc toolchain

[kmentch]

I remember trying to do a npm cache clean at one point and it messed up when I did a paste somewhere and ended up running something else, which I cant find in my terminal history for some reason.

Also note if I run npm commands as sudo I do not get the seg fault error:

sudo npm -v
1.2.2

If you need any other info let me know.

[tjfontaine]

just to be clear, it's nothing npm is doing, I can exhibit this on my laptop with nothing more than running the test suite

[kmentch]

Wow another really weird part, I just ran the node app to see what happens and it runs.... how can npm install fail but running the node app still work??

[indutny]

From my investigation it seems to be a compiler bug, building node it with -O0 resolves the problem.

[indutny]

Yes, this is definitely a compiler bug:

  Space* owner() const {
    if ((reinterpret_cast<intptr_t>(owner_) & kFailureTagMask) ==
        kFailureTag) {
      return reinterpret_cast<Space*>(owner_ - kFailureTag);
    } else {
      return NULL;
    }
  }

compiles into:

   0x1004533fc:  movq   64(%rbx), %rax
   0x100453400:  movq   %rax, %rcx
   0x100453403:  andq   $3, %rcx
   0x100453407:  cmpq   $3, %rcx
   0x10045340b:  jne    0x100453428               ; v8::internal::MemoryAllocator::Free(v8::internal::MemoryChunk*) + 136 at spaces.cc:600
-> 0x10045340d:  movb   13(%rax), %cl
   0x100453410:  movl   $1, %esi
   0x100453415:  shll   %cl, %esi
   0x100453417:  movq   16(%rbx), %rcx
   0x10045341b:  movq   %r14, %rdi
   0x10045341e:  movl   $2, %edx
   0x100453423:  callq  0x100453250               ; v8::internal::MemoryAllocator::PerformAllocationCallback(v8::ObjectSpace, v8::AllocationAction, unsigned long) at spaces.cc:648
...

[indutny]

I can only suggest compiling it with gcc, instead of using clang.

[indutny]

Ok, guided by @bnoordhuis I found that it was fixed in upstream. Backported fix in: 532f9ff, lets wait for next v0.8 release! /cc @tjfontaine

[trevnorris]

@indutny fwiw, I backported the same fix to v0.10 in 5d4ac27. Didn't think about it being a problem in v0.8 at the time.

[indutny]

ok.

[zimbatm]

The latest 0.8 release at http://nodejs.org/dist/v0.8.26/node-v0.8.26.tar.gz doesn't contain the fix. Any plans for a new release ?

[indutny]

cc @tjfontaine

[indutny]

You may try using https://github.com/voxer/node/tree/voxnode-v0.8.26.3 , btw. This is @Voxer 's fork of latest v0.8 node.js

[zimbatm]

Thanks. For now we're just shipping with the patch added.

[tjfontaine]

if there's a security rollup we will probably release a new node, but otherwise shipping with the patch is the best thing to do in the meantime