Hi, I'm trying to track down a periodic SIGSEGV in the node process running my app. (Such things aren't supposed to happen in a type-safe language like Javascript and much of the node community is probably not used to wrestling with such things; the cause must be either a bug in a native-code extension I'm using or a bug in V8's code generation.) I thought running the debug build of node itself might shed some additional light on the problem.
I built node from source (0.10.33) after doing `./configure --debug` and grabbed the resulting out/Debug/node binary [1], and when I run my app with that, it crashes pretty soon with a V8 runtime fatal error message: # # Fatal error in ../deps/v8/src/hydrogen-instructions.cc, line 641 # CHECK(cur == other_operand) failed # It also spits out a backtrace of the Javascript code it was running (well, trying to translate) at the time, and it doesn't always crash at the same point in my program, but it does always crash with this same symptom at hydrogen-instructions.cc:641. I went looking for more standard workloads to run to see if the problem was with my codebase (or, again, the native-code node extensions it uses, bugs in which could mean all bets are off), and I chanced across a minimal repro case in npm itself: with my debug node binary, `npm install archiver connect` crashes the same way. (See here for more details <https://gist.github.com/metamatt/b2aca06fb424559fa7b7>.) So I wonder, does anyone else have experience running the debug node binary and is it known to work better than this? Does the condition that's failing here mean anything to you? Can you repro this, or did I perhaps do something wrong when building node? thanks, Matt [1]: One thing I did learn along the way while playing with building node from source is to be careful with the build configuration, which apparently gets stamped into the node binary and autodetected by node-gyp, which is a problem if you want to build native-code extensions. Normally you do `./configure` without the --debug flag, you build for release, you grab out/Release/node, and node-gyp can tell it's release. If you do `./configure --debug` then `make`, you get both out/Debug/node and out/Release/node, and their own runtime behavior is as you'd expect from the names, but both of them got stamped with default_configuration: debug, so node-gyp thinks they're both debug builds and builds all your native code extensions for debug, which breaks most of the packages with native code you'll find in the npm repository (because package.json or index.js looks for something with Release in the name). And if you do `./configure` without --debug and then do `make node_g`, you get the opposite problem: it builds out/Debug/node but with default_configuration: release stamped into it, and node-gyp will build all the extensions for release. The release extension binaries seem to work fine with the debug node binary and vice versa, as long as whatever loads them can actually find them; I don't know if there are any further problems from mixing and matching but I'm trying to eliminate variables I don't understand. Forrest helped me on Twitter to figure this out (thanks again Forrest). -- Job board: http://jobs.nodejs.org/ New group rules: https://gist.github.com/othiym23/9886289#file-moderation-policy-md Old group rules: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines --- You received this message because you are subscribed to the Google Groups "nodejs" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/nodejs/5f28dd00-340c-4305-b3da-c1a8663866d0%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
