Sqlite3 crashing inside sqlite3_step function

[cppgal]

Hi all,
I am stuggling with a crash of sqlite3 from many days.
I am using sqlite3 3.6.23. I am making one database in different program and using the same database in some other program. First program is creating compressed file of a database and second is decompressing the table from database.

code fregment is as follows :

*************************************

if ((rc = sqlite3_open_v2(dbs, &db, SQLITE_OPEN_READONLY |
SQLITE_OPEN_FULLMUTEX, 0)) != SQLITE_OK)
ACE_ERROR_RETURN((LM_ERROR, "E%03d\t%s: open archive %s erro rc:%d\n",
0, mplg->mName, dbs, rc), -1);

if ((rc = sqlite3_prepare_v2(db, mQuery.c_str(), -1, &stmt, 0)) != SQLITE_OK)
{
ACE_ERROR((LM_ERROR, "E%03d\t%s: prepare %s: %s[%d]\n",
0, mplg->mName, mQuery.c_str(),
sqlite3_errmsg(db), sqlite3_errcode(db)));
sqlite3_close(db);
return -1;
}

....
...
..

while (mplg->mState != STA_SHUTDOWN && !done)
{
if (mMon->getState() == Monitor::PAUSE)
rc = SQLITE_BUSY;
else if (mMon->getState() == Monitor::DONE)
rc = SQLITE_DONE;
else
{
rc = sqlite3_step(stmt);//Segmentation fault inside this function
}

switch (rc)
{
case SQLITE_ROW:

**************************************

Following are the gdb tace and valgrind trace for the segmentation fault:

Program received signal SIGABRT, Aborted.
[Switching to Thread 0x42d88940 (LWP 3399)]
0x0000003a1f430265 in raise () from /lib64/libc.so.6

Program received signal SIGABRT, Aborted.
[Switching to Thread 0x42d88940 (LWP 3399)]
0x0000003a1f430265 in raise () from /lib64/libc.so.6
(gdb) bt
#0 0x0000003a1f430265 in raise () from /lib64/libc.so.6
#1 0x0000003a1f431d10 in abort () from /lib64/libc.so.6
#2 0x0000003a1f46a84b in __libc_message () from /lib64/libc.so.6
#3 0x0000003a1f472fae in _int_malloc () from /lib64/libc.so.6
#4 0x0000003a1f474cde in malloc () from /lib64/libc.so.6
#5 0x00002b43f88bb561 in sqlite3MemMalloc (nByte=1112) at sqlite3.c:12588
#6 0x00002b43f88b9512 in mallocWithAlarm (n=1112, pp=0x42d84e88)
at sqlite3.c:15951
#7 0x00002b43f88b95c9 in sqlite3Malloc (n=1112) at sqlite3.c:15979
#8 0x00002b43f88b9711 in sqlite3DbMallocRaw (db=0x139fa0d8, n=3399)
at sqlite3.c:16287
#9 0x00002b43f88c75d9 in sqlite3VdbeMemGrow (pMem=0x13a23188, n=1112,
preserve=0) at sqlite3.c:46832
#10 0x00002b43f88d4d9a in allocateCursor (p=0x139fffb8, iCur=0, nField=80,
iDb=0, isBtreeCursor=1) at sqlite3.c:52586
#11 0x00002b43f88f0c5f in sqlite3VdbeExec (p=0x139fffb8) at sqlite3.c:55947
#12 0x00002b43f88f0c5f in sqlite3Step (p=0x139fffb8)
from /home/archana/vzw/develop/3dparty/sqlite/lib/libsqlite3.so.0
#13 0x00002b43f88f8100 in sqlite3_step (pStmt=0x139fffb8) at sqlite3.c:51406
#14 0x00002b43f8492612 in Session::getData (this=0x139e4900,
dbs=0x139fabe8 "/home/archana/vzw/data/mpwork/2822-1/.db", flags=0)
at Session.cpp:1155
#15 0x00002b43f849ea92 in Session::getWithSelect (this=0x139e4900,
---Type <return> to continue, or q <return> to quit---
type=0x139f1ca8 "mp", flags=0,
args=0x42d86077 "\"select arc_name from file_ref where arc_name like '%test1%'\" select * from mp") at Session.cpp:896
#16 0x00002b43f849fd07 in Session::get (this=0x139e4900,
args=<value optimized out>) at Session.cpp:518
#17 0x00002b43f8494ada in Session::svc (this=0x139e4900) at Session.cpp:268
#18 0x00002b43f79c8987 in ACE_Task_Base::svc_run (args=<value optimized out>)
at Task.cpp:275
#19 0x00002b43f79c9905 in ACE_Thread_Adapter::invoke (this=0x139e5860)
at Thread_Adapter.cpp:98
#20 0x0000003a2000673d in start_thread () from /lib64/libpthread.so.0
#21 0x0000003a1f4d3d1d in clone () from /lib64/libc.so.6

And valgrind log is :

--13174-- --leak-check=full
--13174-- --main-stacksize=400000
--13174-- -v
--13174-- Contents of /proc/version:
--13174-- Linux version 2.6.18-194.el5 ([e-mail]) (gcc version 4.1.2 20080704 (Red Hat 4.1.2-48)) #1 SMP Tue Mar 16 21:52:39 EDT 2010
--13174-- Arch and hwcaps: AMD64, amd64-sse3-cx16-lzcnt
--13174-- Page sizes: currently 4096, max supported 4096
--13174-- Valgrind library directory: /usr/local/lib/valgrind
--13174-- Reading syms from /home/archana/vzw/plugins/libL2SS.so.3.0.4 (0x108000)
--13174-- Reading syms from /usr/local/lib/valgrind/memcheck-amd64-linux (0x38000000)
--13174-- object doesn't have a dynamic symbol table
--13174-- Reading suppressions file: /usr/local/lib/valgrind/default.supp
==13174==
==13174== Process terminating with default action of signal 11 (SIGSEGV)
==13174== Access not within mapped region at address 0x0
==13174== at 0x1: ???
==13174== by 0x7FF000792: ???
==13174== If you believe this happened as a result of a stack
==13174== overflow in your program's main thread (unlikely but
==13174== possible), you can try to increase the size of the
==13174== main thread stack using the --main-stacksize= flag.
==13174== The main thread stack size used in this run was 1048576.
==13174==
==13174== HEAP SUMMARY:
==13174== in use at exit: 0 bytes in 0 blocks
==13174== total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==13174==
==13174== All heap blocks were freed -- no leaks are possible
==13174==
==13174== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
==13174== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)


Waiting for your reply
-Archana
sse@AgilisInternation

[kooth]

Obviously the code is trying to write to address 0, so you could have a NULL pointer. Make sure stmt isn't NULL.

[Moschops]

If you build it with debug symbols, valgrind will tell you the exact line of code that tries to dereference a null pointer.

[kbw]

First program is creating compressed file of a database and second is decompressing the table from database.

Shouldn't you be decompressing the database and not just a table? You're not entirely clear on whast exactly you're doing.