Segmentation Fault Under Node v0.11.14

[senditu]

I'm running into a segfault under ArchLinux x64 (3.16.3-1-ARCH). I downloaded a fresh copy of Node from the Node dist site (http://nodejs.org/dist/v0.11.14/) and proceeded to do an npm install for a sqlite-based website app that works fine under v0.11 on Windows x64. When running the app I get a segfault. I tracked down the seqfault to the initial load of the dbs in my app (the are no other lines invoking the sqlite3 library before these lines)...

The following code is in LiveScript.

log 'hihi'
db = new sqlite3.Database('db.sqlite')
log 'hihi2'
ip-db = new sqlite3.Database('ipdb.sqlite')
log 'byebye'

Here's the output:

$ ~/bin/lsc scrape.ls
[3:33:05 pm] hihi
[1]    3110 segmentation fault (core dumped)  ~/bin/lsc scrape.ls

Oct 10 15:33:05 m kernel: node[3116]: segfault at b6d168 ip 00007f365980c142 sp 00007f365b231e30 error 7
Oct 10 15:33:05 m kernel: node[3117]: segfault at b6d168 ip 00007f365980c142 sp 00007f365aa30e30 error 7
Oct 10 15:33:05 m kernel:  in node_sqlite3.node[7f3659718000+112000]
Oct 10 15:33:05 m kernel:  in node_sqlite3.node[7f3659718000+112000]
Oct 10 15:33:26 m systemd-coredump[3119]: Process 3110 (node) of user 1000 dumped core.

The application runs fine under Windows 8.1 x64 with Node v0.11.14. It also runs fine under ArchLinux x64 with Node v0.10.32. Just not Linux with v0.11.14, it seems. I also tried adding the git repository directly into package.json ("sqlite3": "git://github.com/developmentseed/node-sqlite3.git") with no effect. I'd really like to use sqlite3 with Node v0.11.14, if possible. Does anyone know what could be going on here?

Thank you!

[PierrickP]

Same here under fedora 20 & travis-ci 😞
Which other details can i provide you ?

[jaswilli]

For what it's worth, it appears to be some sort of issue with the precompiled binding. If I npm install sqlite3 --build-from-source everything works fine.

Here's the backtrace when using the "bad" binding:

vagrant@vagrant-ubuntu-precise-64:~/src/s3$ gdb `which node` core
GNU gdb (Ubuntu/Linaro 7.4-2012.04-0ubuntu2.1) 7.4-2012.04
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
<http://bugs.launchpad.net/gdb-linaro/>...
Reading symbols from /home/vagrant/nvm/v0.11.14/bin/node...done.
[New LWP 8381]
[New LWP 8377]
[New LWP 8380]
[New LWP 8379]
[New LWP 8378]

warning: Can't read pathname for load map: Input/output error.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `node t.js'.
Program terminated with signal 11, Segmentation fault.
#0  0x00007fcd8c9bb142 in openDatabase ()
   from /home/vagrant/src/s3/node_modules/sqlite3/lib/binding/node-v14-linux-x64/node_sqlite3.node
(gdb) bt
#0  0x00007fcd8c9bb142 in openDatabase ()
   from /home/vagrant/src/s3/node_modules/sqlite3/lib/binding/node-v14-linux-x64/node_sqlite3.node
#1  0x00007fcd8c8d9f0b in node_sqlite3::Database::Work_Open(uv_work_s*) ()
   from /home/vagrant/src/s3/node_modules/sqlite3/lib/binding/node-v14-linux-x64/node_sqlite3.node
#2  0x0000000000b6d3a9 in worker (arg=<optimized out>)
    at ../deps/uv/src/threadpool.c:91
#3  0x0000000000b6dec1 in uv__thread_start (arg=<optimized out>)
    at ../deps/uv/src/uv-common.c:278
#4  0x00007fcd8cfa5e9a in start_thread ()
   from /lib/x86_64-linux-gnu/libpthread.so.0
#5  0x00007fcd8ccd331d in clone () from /lib/x86_64-linux-gnu/libc.so.6
#6  0x0000000000000000 in ?? ()
(gdb) 

[springmeyer]

@jaswilli - thanks for that realization - it makes sense because latest node-sqlite3 binaries were packaged against node v0.11.13 and not v0.11.14. Reading nodejs/node-v0.x-archive#5789 seems to confirm that each patch-level odd-numbered (e.g. unstable) node.js release may break ABI without incrementing the NODE_MODULE_VERSION which is a problem for node-pre-gyp packaged binaries which depend on NODE_MODULE_VERSION to know what ABI the user needs. So it looks like there are a few solutions to this:

1. Have Ghost target node v0.11.13 instead of v0.11.14
2. Have Ghost wait until node v0.12.0 is released to actually try to track new Node.js
3. Retag and publish a new node-sqlite3 release whose binaries target the new node v0.11.14 release
4. Have node-pre-gyp modify its versioning logic so that only even nodejs releases use NODE_MODULE_VERSION and odd nodejs releases ignore it and assume that every patch release is binary-incompatible with the previous patch release.

I think 2) would be the most solid solution and 4) is necessary long term way to avoid a breakage like this (although it would introduce other breakages since it is not realistic to support binaries for every patch release of unstable node.js releases!).

[jaswilli]

I completely agree.

2. is what we're doing--as I said over on the Ghost issue tracker, I'm just doing some proactive testing against node 0.11. And 4) sounds like it might be a good plan going forward.

I certainly don't need a new version of node-sqlite3 tagged and released for this, I'm perfectly happy compiling the bindings on my own for testing purposes.

Thanks for all your work on this project. It's a great package and always very easy to work with.

[ErisDS]

Closing as I believe this was a version incompatibility issue with unstable node, and this should no longer be a problem.