Running SQLite3 calls in a loop.

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Running SQLite3 calls in a loop.

Toni Spets
Hi!

I have been working with my statistics system for a while. I was
looking for a simple and fast SQL-system to use and decided to go on
with SQLite.

There have been many problems with SQLite3 and memory allocation. I'm
using only sqlite3_exec() in my code, so it should clean up after its
done, right?

Unfortunately, it's not working very well. It might be
PEBKAC-situation here, but I have no clue what to do.

Here is a clip from GDB:
-- snip --
Program received signal SIGSEGV, Segmentation fault.
0xb7ebb03e in mallopt () from /lib/libc.so.6
(gdb) bt
#0  0xb7ebb03e in mallopt () from /lib/libc.so.6
#1  0xb7eb9c9f in free () from /lib/libc.so.6
#2  0xb7fa7cf3 in sqlite3FreeX (p=0xb7f6caa4) at util.c:287
#3  0xb7f9592b in pager_reset (pPager=0x488) at pager.c:829
#4  0xb7f97e11 in sqlite3pager_unref (pData=0x8051520) at pager.c:2595
#5  0xb7f7ba76 in releasePage (pPage=0xb7f6caa4) at btree.c:1157
#6  0xb7f7c194 in unlockBtreeIfUnused (pBt=0x804c338) at btree.c:1516
#7  0xb7f7cb55 in sqlite3BtreeCommit (pBt=0x804c338) at btree.c:1948
#8  0xb7fb18a6 in vdbeCommit (db=0x804c050) at vdbeaux.c:1015
#9  0xb7fb1b55 in sqlite3VdbeHalt (p=0x8050e58) at vdbeaux.c:1220
#10 0xb7fab867 in sqlite3VdbeExec (p=0x8050e58) at vdbe.c:636
#11 0xb7faf5b8 in sqlite3_step (pStmt=0x8050e58) at vdbeapi.c:211
#12 0xb7fb6e6b in sqlite3_exec (db=0x804c050, zSql=0xbfee55a0 "DELETE
FROM stats WHERE chk == 0 AND server == '193.65.46.32:27920';",
xCallback=0, pArg=0x0,
    pzErrMsg=0x0) at legacy.c:79
#13 0x08049dbe in main ()
-- snap --

The funny thing is, that this loop works fine for like 5 minutes and
then crashes at random place. Am I missing something (like free()ing)
or is the SQlite3 really forgetting something.

Thanks!

- Toni Spets
Reply | Threaded
Open this post in threaded view
|

Re: Running SQLite3 calls in a loop.

D. Richard Hipp
On Sat, 2005-06-11 at 21:33 +0300, Toni Spets wrote:

> Here is a clip from GDB:
> -- snip --
> Program received signal SIGSEGV, Segmentation fault.
> 0xb7ebb03e in mallopt () from /lib/libc.so.6
> (gdb) bt
> #0  0xb7ebb03e in mallopt () from /lib/libc.so.6
> #1  0xb7eb9c9f in free () from /lib/libc.so.6
> #2  0xb7fa7cf3 in sqlite3FreeX (p=0xb7f6caa4) at util.c:287

> The funny thing is, that this loop works fine for like 5 minutes and
> then crashes at random place. Am I missing something (like free()ing)
> or is the SQlite3 really forgetting something.
>

This might be a problem with SQLite.  But a more likely
explanation is that something in your program is munging
the malloc memory pool.  Perhaps your program is freeing
some memory twice, or continuing to use (and modify) memory
after it is freed, or overrunning a buffer obtained from
malloc().
--
D. Richard Hipp <[hidden email]>

Reply | Threaded
Open this post in threaded view
|

Re: Running SQLite3 calls in a loop.

Toni Spets
(Forwarded this message to the mailing list. My bad.)

Hi!

The program doesn't use any dynamic memory allocation at all (besides
SQLite3 and another library of mine). It doesn't make any sense.

I attached the main.c which is used to call SQLite3.

And yes, I know it's pretty crappy code :-). There might be something
funny around because of the debugging and stuff.

Thanks for your help!

- Toni Spets

On 6/11/05, D. Richard Hipp <[hidden email]> wrote:

> On Sat, 2005-06-11 at 21:33 +0300, Toni Spets wrote:
>
> > Here is a clip from GDB:
> > -- snip --
> > Program received signal SIGSEGV, Segmentation fault.
> > 0xb7ebb03e in mallopt () from /lib/libc.so.6
> > (gdb) bt
> > #0  0xb7ebb03e in mallopt () from /lib/libc.so.6
> > #1  0xb7eb9c9f in free () from /lib/libc.so.6
> > #2  0xb7fa7cf3 in sqlite3FreeX (p=0xb7f6caa4) at util.c:287
>
> > The funny thing is, that this loop works fine for like 5 minutes and
> > then crashes at random place. Am I missing something (like free()ing)
> > or is the SQlite3 really forgetting something.
> >
>
> This might be a problem with SQLite.  But a more likely
> explanation is that something in your program is munging
> the malloc memory pool.  Perhaps your program is freeing
> some memory twice, or continuing to use (and modify) memory
> after it is freed, or overrunning a buffer obtained from
> malloc().
> --
> D. Richard Hipp <[hidden email]>
>
>