Segmentation Fault

[markmitton]

Hi,

We have been using sqlite3 module successfully for quite some time in an embedded application. Recent updates to the app make more heavily use of the database and the node VM now gets a segmentation fault.

The error happens sporadically and sometimes even when the app is not writing to the database and just idling.

Any help would be appreciated.

Node: 6.10.3
Npm: 3.10.10
Architecture: armv7l
OS: GNU/Linux

Program terminated with signal SIGSEGV, Segmentation fault.
#0 sqlite3_db_mutex (db=0x0) at Release/obj/gen/sqlite-autoconf-3150000/sqlite3.c:138532

warning: Source file is more recent than executable.
138532 }
[Current thread is 1 (LWP 25481)]
(gdb) list
138527 (void)SQLITE_MISUSE_BKPT;
138528 return 0;
138529 }
138530 #endif
138531 return db->mutex;
138532 }
138533
138534 /*
138535 ** Free up as much memory as we can from the given database
138536 ** connection.
(gdb) bt
#0 sqlite3_db_mutex (db=0x0) at Release/obj/gen/sqlite-autoconf-3150000/sqlite3.c:138532
#1 0xb481a668 in node_sqlite3::Statement::Work_Prepare (req=) at ../src/statement.cc:128
#2 0x00866d44 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Regards
Mark

[markmitton]

Some more info from gdb ...

Program terminated with signal SIGSEGV, Segmentation fault.
#0 sqlite3_db_mutex (db=0x0) at Release/obj/gen/sqlite-autoconf-3150000/sqlite3.c:138532

warning: Source file is more recent than executable.
138532 }
[Current thread is 1 (LWP 25481)]
(gdb) list
138527 (void)SQLITE_MISUSE_BKPT;
138528 return 0;
138529 }
138530 #endif
138531 return db->mutex;
138532 }
138533
138534 /*
138535 ** Free up as much memory as we can from the given database
138536 ** connection.
(gdb) bt
#0 sqlite3_db_mutex (db=0x0) at Release/obj/gen/sqlite-autoconf-3150000/sqlite3.c:138532
#1 0xb481a668 in node_sqlite3::Statement::Work_Prepare (req=) at ../src/statement.cc:128
#2 0x00866d44 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb) p db
$1 = (sqlite3 *) 0x0
(gdb) info threads
Id Target Id Frame

• 1 LWP 25481 sqlite3_db_mutex (db=0x0) at Release/obj/gen/sqlite-autoconf-3150000/sqlite3.c:138532
  2 LWP 25482 0xb6b6a8d0 in pthread_cond_wait () from /lib/libpthread.so.0
  3 LWP 25358 0xb6b6cd58 in ?? () from /lib/libpthread.so.0
  4 LWP 25359 0xb6b6cd58 in ?? () from /lib/libpthread.so.0
  5 LWP 25360 0xb6b6cd58 in ?? () from /lib/libpthread.so.0
  6 LWP 25361 0xb6b6cd58 in ?? () from /lib/libpthread.so.0
  7 LWP 25362 0xb6b6cd58 in ?? () from /lib/libpthread.so.0
  8 LWP 25483 0xb6b6a8cc in pthread_cond_wait () from /lib/libpthread.so.0
  9 LWP 25484 0xb6b6a8cc in pthread_cond_wait () from /lib/libpthread.so.0
  10 LWP 25356 0x004e8094 in v8::internal::IC::IC(v8::internal::IC::FrameDepth, v8::internal::Isolate*, v8::internal::FeedbackNexus*) ()
  (gdb)

[springmeyer]

What node-sqlite3 version are you running/experiencing this crash with? If you are running v4.0.2 can you check if downgrading to 4.0.0 fixes the sporadic crash? Asking since 4.0.1 upgraded the internal sqlite library version to 3.24.0: https://github.com/mapbox/node-sqlite3/blob/master/CHANGELOG.md#401

[markmitton]

@springmeyer thanks for your reply.

The crash was occurring in node-sqlite 3.1.9 with bundled sqlite library version 3.15. I since then installed node-sqlite 4.0.2 with bundled sqlite library version 3.24, ran for almost 2 hours under heavy load and also crashed.

Cored info below looks the same.

.
.
.

Program terminated with signal SIGSEGV, Segmentation fault.
#0 sqlite3_db_mutex (db=0x0) at Release/obj/gen/sqlite-autoconf-3240000/sqlite3.c:147533

warning: Source file is more recent than executable.
147533 }
[Current thread is 1 (LWP 1013)]
(gdb) list
147528 (void)SQLITE_MISUSE_BKPT;
147529 return 0;
147530 }
147531 #endif
147532 return db->mutex;
147533 }
147534
147535 /*
147536 ** Free up as much memory as we can from the given database
147537 ** connection.
(gdb) bt
#0 sqlite3_db_mutex (db=0x0) at Release/obj/gen/sqlite-autoconf-3240000/sqlite3.c:147533
#1 0xb25152d8 in node_sqlite3::Statement::Work_Prepare (req=) at ../src/statement.cc:128
#2 0x00866d44 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb) p db
$1 = (sqlite3 *) 0x0
(gdb) info threads
Id Target Id Frame

• 1 LWP 1013 sqlite3_db_mutex (db=0x0) at Release/obj/gen/sqlite-autoconf-3240000/sqlite3.c:147533
  2 LWP 722 0xb6acad58 in ?? () from /lib/libpthread.so.0
  3 LWP 723 0xb6acad58 in ?? () from /lib/libpthread.so.0
  4 LWP 724 0xb6acad58 in ?? () from /lib/libpthread.so.0
  5 LWP 725 0xb6acad58 in ?? () from /lib/libpthread.so.0
  6 LWP 726 0xb6acad58 in ?? () from /lib/libpthread.so.0
  7 LWP 1014 0xb6ac88cc in pthread_cond_wait () from /lib/libpthread.so.0
  8 LWP 1015 0xb6ac88cc in pthread_cond_wait () from /lib/libpthread.so.0
  9 LWP 1016 0xb6ac88cc in pthread_cond_wait () from /lib/libpthread.so.0
  10 LWP 721 0xb6ac64ec in ?? () from /lib/libpthread.so.0

[markmitton]

I may just attempt to edit the makefile to build with SQLITE_ENABLE_API_ARMOR defined. Offending code snippet below.

/*
** Return the mutex associated with a database connection.
*/
SQLITE_API sqlite3_mutex *sqlite3_db_mutex(sqlite3 *db){
#ifdef SQLITE_ENABLE_API_ARMOR
if( !sqlite3SafetyCheckOk(db) ){
(void)SQLITE_MISUSE_BKPT;
return 0;
}
#endif
return db->mutex;
}

[mohd-akram]

I got this error today:

PID 64555 received SIGSEGV for address: 0x18
/home/mohamed/Development/project/node_modules/segfault-handler/build/Release/segfault-handler.node(+0x2e45)[0x7f3e3d149e45]
/lib64/libpthread.so.0(+0x14a90)[0x7f3e3a3e3a90]
/home/mohamed/Development/project/node_modules/sqlite3/lib/binding/napi-v3-linux-x64/node_sqlite3.node(sqlite3_db_mutex+0x0)[0x7f3e343b9730]
/home/mohamed/Development/project/node_modules/sqlite3/lib/binding/napi-v3-linux-x64/node_sqlite3.node(_ZN12node_sqlite39Statement12Work_PrepareEP10napi_env__Pv+0x23)[0x7f3e34393bd3]
/lib64/libnode.so.72(+0xdd9bd4)[0x7f3e3b1cabd4]
/lib64/libpthread.so.0(+0x9432)[0x7f3e3a3d8432]
/lib64/libc.so.6(clone+0x43)[0x7f3e3a306913]
Segmentation fault (core dumped)

[mohd-akram]

The DB was closed before an insert finished, hence the crash. An error message would be nice.