Segmentation fault - how to diagnose?

[Graeme Foster]

Hi all

I'm using node 0.8.14 and I've got a test suite that results in a segmentation fault on both OSX and whatever Travis is building on. I thought I'd be clever and use gdb to get a stack trace but here's what I got:


(gdb) set args ./node_modules/mocha/bin/mocha
(gdb) run
Starting program: /usr/local/bin/node ./node_modules/mocha/bin/mocha
Reading symbols for shared libraries ++++......................................................................................................................................... done
․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․
Program received signal SIGSEGV, Segmentation fault.
0x00007fff98797d46 in __kill ()
(gdb) bt
#0 0x00007fff98797d46 in __kill ()
(gdb)

So that's not too useful :/

What can I do next to track down the problem? I have no native code myself so I think the problem must be occurring in libxmljs, contextify, or rbytes, but I don't know which. I'm afraid I haven't done anything with native code in over a decade and even then it was on Windows so I'm just a little out of my comfort zone here... :/

If you'd like to help investigate (me love you long time) you can see the output from Travis at https://travis-ci.org/#!/GraemeF/wordburglar/builds/3071625 and repeat the test yourself by cloning https://github.com/GraemeF/wordburglar.git and run npm install and then npm test.

Any tips would be appreciated!

Cheers,
G.
--
Twitter: @GraemeF
IRC: graeme_f

[mscdex]

On Nov 7, 3:49 pm, Graeme Foster <grae...@gmail.com> wrote:
> Any tips would be appreciated!

I'd first start by making debug builds of all addon dependencies and
using those instead. You can do it manually by going into each addon's
top-level directory and doing `node-gyp --debug rebuild` (you might
want/need to `npm install node-gyp -g` first to do this). Then try
running gdb....

[Graeme Foster]

Oops, I forgot about browserify... Run this and then the tests will pass (up to the seg fault):

mkdir public
node_modules/browserify/bin/cmd.js --entry client/src/lib/main.js -o public/client.js

Cheers,
G.

On Wednesday, November 7, 2012 9:45:01 PM UTC, Paul Serby wrote:

Sorry I've just seen that yours runs more tests before seg faulting.

Any ideas why I get that error?

[Paul Serby]

I attached segvhandler (https://github.com/ddopson/node-segfault-handler) and got the following: https://gist.github.com/4039738

Looks like it is in contextify.node

If you run the tests in isolation you don't get the error. It could be down to a overflow or leak somewhere that only shows its head when you use a lot of zombie instances.

[Ben Noordhuis]

On Thu, Nov 8, 2012 at 5:18 PM, Paul Serby <paul....@clock.co.uk> wrote:
> I attached segvhandler (https://github.com/ddopson/node-segfault-handler)
> and got the following: https://gist.github.com/4039738
>
> Looks like it is in contextify.node
>
> If you run the tests in isolation you don't get the error. It could be down
> to a overflow or leak somewhere that only shows its head when you use a lot
> of zombie instances.

Turn on core dumps (`ulimit -c unlimited`) and inspect them with gdb
(that's `gdb /path/to/node /path/to/core`). If you are on OS X, the
cores are stored in /cores instead of $PWD, IIRC. Happy hunting. :-)

[Graeme Foster]

Thanks chaps; consider that can of worms well and truly opened :)

I didn't come across segvhandler when I was searching for info - looks very handy!

Cheers,

G.