On Thu, Nov 10, 2016 at 11:52 AM, Richard Hipp <d...@sqlite.org> wrote:
> On 11/10/16, pisymbol . <pisym...@gmail.com> wrote:
> > sqlite-3.6.20-1.el6_7.2.i686
> > sqlite-3.6.20-1.el6_7.2.x86_64
>
> Are you aware that SQLite 3.6.20 was published over 7 years ago on
> 2009-11-04 and that there have been 82 subsequent releases of SQLite
> and that the newer releases run more than twice as fast?
>
> Maybe the right solution is updated to SQLite 3.15.1?
>
It could very well be. So it happened again (SIGSEGV) on start up:
(gdb) bt
#0 0x0000003af560c713 in ?? () from /usr/lib64/libsqlite3.so.0
#1 0x0000003af5651cc7 in ?? () from /usr/lib64/libsqlite3.so.0
#2 0x0000003af56537c1 in ?? () from /usr/lib64/libsqlite3.so.0
#3 0x0000003af5655d67 in ?? () from /usr/lib64/libsqlite3.so.0
#4 0x0000003af5655ec9 in ?? () from /usr/lib64/libsqlite3.so.0
#5 0x0000003af5656118 in sqlite3_prepare_v2 () from
/usr/lib64/libsqlite3.so.0
...
And the line that caused it was this:
1774 sqlite3_stmt *stmt = NULL;
1773 if (sqlite3_prepare_v2(db, SELECT_JOBS_QUERY, -1, &stmt, NULL)
!= 0) {
And that is a hard coded SQL SELECT statement (C macro). Very innocuous
with respect to SQL. The db handle was opened using sqlite3_open().
I guess this is just some kind of timing/multithreaded bug? I believe
another thread was querying a different table when this happened using the
same handle (selecting one column). No transactions locks are held in
either case, i.e. BEGIN EXCLUSIVE et al.
Provided my assumption that I'm doing nothing really wrong, I guess I'll
try static linking a newer version of sqlite3 to see if it disappears.
-aps
_______________________________________________
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
