On Sep 29, 2009, at 4:30 PM, Ralf Junker wrote:
> My memory manager reports that the SQL below results in memory being
> reused after it has already been freed when it is RUN FOR A SECOND
> TIME on the same database connection.
Hi Ralf,
Thanks for this report. I'm unable to reproduce the problem so far
though. Are you compiling SQLite with any special symbols or anything
like that?
Are you able to build other programs using this memory manager? If so,
does the bug show up when you pass the problematic SQL to the command
line tool twice? Or if I send you a C program are you able to build and
test it?
Thanks,
Dan.
> Psydocode (I do not run C):
>
> sqlite3_initialize;
> sqlite3_open(DB_FILE_NAME, &DB);
> sqlite3_exec(DB, SQL, NULL, NULL, NULL);
> sqlite3_exec(DB, SQL, NULL, NULL, NULL);
> sqlite3_close(DB);
> sqlite3_shutdown;
>
> The database file does not exist before running sqlite3_open().
>
> I can reproduce the problem reliably with [e4eb227b14]. There were
> simmilar memory reports during the development of fkeys.c. They have
> been fixed by [5b4d46374a] except for the one mentioned here.
>
> Finally, here is the SQL:
>
> PRAGMA foreign_keys = 0;
> DROP TABLE IF EXISTS t1;
> DROP TABLE IF EXISTS t2;
>
> PRAGMA foreign_keys = 1;
> CREATE TABLE t1(a PRIMARY KEY, b UNIQUE);
> CREATE TABLE t2(x REFERENCES t1 ON UPDATE CASCADE ON DELETE CASCADE);
> INSERT INTO t1 VALUES('aaa', 1);
> INSERT INTO t2 VALUES('aaa');
> UPDATE t1 SET a = 'bbb';
> DELETE FROM t1;
>
> PRAGMA foreign_keys = 0;
> DROP TABLE t1;
> DROP TABLE t2;
>
> PRAGMA foreign_keys = 1;
> CREATE TABLE t1(x, y, PRIMARY KEY(x, y));
> CREATE TABLE t2(a, b, FOREIGN KEY(a, b) REFERENCES t1 ON UPDATE
> CASCADE);
> INSERT INTO t1 VALUES(1, 2);
> INSERT INTO t2 VALUES(1, 2);
> UPDATE t1 SET x = 5;
>
> Ralf
>
> ------------
>
> Call stack leading to the problem:
>
> Modified byte offsets (and lengths): 512(6)
>
> The previous block size was: 2048
>
> This block was previously allocated by thread 0x8BC, and the stack
> trace (return addresses) at the time was:
> 4088CE [DebugReallocMem]
> 413A48 [realloc][4198]
> 453A7E [...@sqlite3realloc]
> 453AF9 [sqlite3_realloc]
> 453C22 [...@sqlite3dbrealloc]
> 440AE6 [...@sqlite3vdbeswap]
> 440B37 [...@sqlite3vdbeaddop3]
> 440B8F [...@sqlite3vdbeaddop0]
> 4256CE [...@sqlite3triggersexist]
> 4539A3 [...@sqlite3dbfree]
> 425894 [...@sqlite3triggersexist]
>
> The allocation number was: 632
>
> The block was previously freed by thread 0x8BC, and the stack trace
> (return addresses) at the time was:
> 413781 [Free][3285]
> 45397C [sqlite3_free]
> 4539C7 [...@sqlite3dbfree]
> 440FA2 [...@sqlite3vdbejumphere]
> 440FD2 [...@sqlite3vdbeprogramdelete]
> 440F5F [...@sqlite3vdbejumphere]
> 440F88 [...@sqlite3vdbejumphere]
> 44265B [...@sqlite3vdbedelete]
> 4425A5 [...@sqlite3vdbefinalize]
> 42DA71 [sqlite3_exec]
> 45B9F7 [D:\DI_Stable\Lib\SQLite3\Test\Test.dpr][Test][initialization]
> [45]
>
> The current thread ID is 0x8BC, and the stack trace (return
> addresses) leading to this error is:
> 408698 [DebugGetMem]
> 4088CE [DebugReallocMem]
> 413A48 [realloc][4198]
> 453A7E [...@sqlite3realloc]
> 453AF9 [sqlite3_realloc]
> 453C22 [...@sqlite3dbrealloc]
> 440AE6 [...@sqlite3vdbeswap]
> 440B37 [...@sqlite3vdbeaddop3]
> 440B8F [...@sqlite3vdbeaddop0]
> 4256CE [...@sqlite3triggersexist]
> 4539A3 [...@sqlite3dbfree]
>
> Current memory dump of 256 bytes starting at pointer address 7FEE3CD0:
> A0 DC 46 00 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80
> 80 80 80 80 80 80 80 80 80
> 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80
> 80 80 80 80 80 80 80 80 80
> 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80
> 80 80 80 80 80 80 80 80 80
> 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80
> 80 80 80 80 80 80 80 80 80
> 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80
> 80 80 80 80 80 80 80 80 80
> 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80
> 80 80 80 80 80 80 80 80 80
> 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80
> 80 80 80 80 80 80 80 80 80
> 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80
> 80 80 80 80 80 80 80 80 80
> Ü F . € € € € € € € € € € € € € € € € € € €
> € € € € € € € € €
> € € € € € € € € € € € € € € € € € € € € € € €
> € € € € € € € € €
> € € € € € € € € € € € € € € € € € € € € € € €
> € € € € € € € € €
> € € € € € € € € € € € € € € € € € € € € € € €
> € € € € € € € € €
> € € € € € € € € € € € € € € € € € € € € € € €
> € € € € € € € € €
> € € € € € € € € € € € € € € € € € € € € € € €
> € € € € € € € € €
> € € € € € € € € € € € € € € € € € € € € € € €
> € € € € € € € € €
> € € € € € € € € € € € € € € € € € € € € € € €
> € € € € € € € € €
>
> _______________________________________________
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
