I confirmed your "memory leak". What you're seeing is the page cache growing.
Not really a memory leak. Default page cache size is 2000 and indeed if I just
let it run it topped out at 5404 RES in top.
I added dmalloc to sqlite3 and found that if you let your program loop several
times and politely exit there is no memory leak.
So I added some debug statements in sqlite3.c to the alloc and free sections.
It produced an output like this:
alloc 664 0x2ac150a61408
alloc 3224 0x2aaaaaab9008
alloc 360 0x2aaaaaaab008
alloc 1016 0x2aaaaaac7808
free 0x2aaaaaab9008
free 0x2ac150a61408
free 0x2aaaaaac7808
free 0x2aaaaaaab008
I ran just two iterations of your program and edited the log to remove
everything except the iteration between 1 & 2.
"grep alloc log | wc -l" and "grep free log" show that the 1st loop through
your program shows 811 allocs and 809 frees. So there are two places where
memory is not getting freed.
I then wrote a quick log analysis that showed
free not found for 0x2ac150a63808
free not found for 0x2aaaaaac7008
grep for those two addresses showed
alloc 1280 0x2ac150a63808
alloc 1280 0x2aaaaaac7008
There are only two 1280 alloc's in the log do I added a debug statement in
sqlite3MemMalloc to trigger on 1280 bytes.
Stepping through the debug then showed me at this point (line#'s are
approximate as I've added statements) for both alloc's that occur:
Breakpoint 1, sqlite3MemMalloc (nByte=1272) at sqlite3.c:12977
#0 sqlite3MemMalloc (nByte=1272) at sqlite3.c:12977
#1 0x0000000000405b17 in mallocWithAlarm (n=1272, pp=0x7fff655c1248) at
sqlite3.c:16343
#2 0x0000000000405bbc in sqlite3Malloc (n=1272) at sqlite3.c:16371
#3 0x000000000040fc5c in pcache1Alloc (nByte=1272) at sqlite3.c:31163
#4 0x000000000040fd39 in pcache1AllocPage (pCache=0x2acd74d1eb90) at
sqlite3.c:31197
#5 0x00000000004105ca in pcache1Fetch (p=0x2acd74d1eb90, iKey=1, createFlag=2)
at sqlite3.c:31566
#6 0x000000000040f2f3 in sqlite3PcacheFetch (pCache=0x2acd74d288f0, pgno=1,
createFlag=1,
ppPage=0x7fff655c1400) at sqlite3.c:30645
#7 0x000000000041470b in sqlite3PagerAcquire (pPager=0x2acd74d28810, pgno=1,
ppPage=0x7fff655c1400,
noContent=0) at sqlite3.c:36020
#8 0x0000000000418492 in btreeGetPage (pBt=0x2acd74d29c10, pgno=1,
ppPage=0x7fff655c1450, noContent=0)
at sqlite3.c:40101
#9 0x00000000004193bc in lockBtree (pBt=0x2acd74d29c10) at sqlite3.c:40811
#10 0x00000000004199a2 in sqlite3BtreeBeginTrans (p=0x2acd74d1ee90, wrflag=0)
at sqlite3.c:41061
#11 0x0000000000455de7 in sqlite3InitOne (db=0x2acd74d28c10, iDb=0,
pzErrMsg=0x2acd74d28420)
at sqlite3.c:79614
#12 0x000000000045629d in sqlite3Init (db=0x2acd74d28c10,
pzErrMsg=0x2acd74d28420) at sqlite3.c:79784
#13 0x0000000000456384 in sqlite3ReadSchema (pParse=0x2acd74d28410) at
sqlite3.c:79821
#14 0x0000000000442d4a in sqlite3StartTable (pParse=0x2acd74d28410,
pName1=0x2aaaaaab90e8,
pName2=0x2aaaaaab9108, isTemp=0, isView=0, isVirtual=0, noErr=0) at
sqlite3.c:68162
#15 0x000000000046bf2e in yy_reduce (yypParser=0x2aaaaaab9010, yyruleno=26) at
sqlite3.c:94009
#16 0x000000000046f67e in sqlite3Parser (yyp=0x2aaaaaab9010, yymajor=22,
yyminor=
{z = 0x47b36e "(id INTEGER PRIMARY KEY, d1 CHAR(16))", n = 1},
pParse=0x2acd74d28410)
at sqlite3.c:95191
#17 0x000000000047037b in sqlite3RunParser (pParse=0x2acd74d28410,
zSql=0x47b358 "CREATE TABLE data_his (id INTEGER PRIMARY KEY, d1
CHAR(16))", pzErrMsg=0x7fff655c1980)
at sqlite3.c:96017
#18 0x00000000004566fd in sqlite3Prepare (db=0x2acd74d28c10,
zSql=0x47b358 "CREATE TABLE data_his (id INTEGER PRIMARY KEY, d1
CHAR(16))", nBytes=-1,
saveSqlFlag=0, pReprepare=0x0, ppStmt=0x7fff655c1ac8,
pzTail=0x7fff655c1ad0) at sqlite3.c:79995
#19 0x0000000000456a2b in sqlite3LockAndPrepare (db=0x2acd74d28c10,
zSql=0x47b358 "CREATE TABLE data_his (id INTEGER PRIMARY KEY, d1
CHAR(16))", nBytes=-1,
saveSqlFlag=0, pOld=0x0, ppStmt=0x7fff655c1ac8, pzTail=0x7fff655c1ad0) at
sqlite3.c:80090
#20 0x0000000000456b97 in sqlite3_prepare (db=0x2acd74d28c10,
zSql=0x47b358 "CREATE TABLE data_his (id INTEGER PRIMARY KEY, d1
CHAR(16))", nBytes=-1,
ppStmt=0x7fff655c1ac8, pzTail=0x7fff655c1ad0) at sqlite3.c:80153
#21 0x0000000000451bc7 in sqlite3_exec (db=0x2acd74d28c10,
zSql=0x47b358 "CREATE TABLE data_his (id INTEGER PRIMARY KEY, d1
CHAR(16))", xCallback=0, pArg=0x0,
pzErrMsg=0x0) at sqlite3.c:76835
#22 0x0000000000401d8a in main () at thread.c:16
Michael D. Black
Senior Scientist
Northrop Grumman Mission Systems
________________________________
From: sqlite-users-boun...@sqlite.org on behalf of liubin liu
Sent: Sat 4/24/2010 1:58 AM
To: sqlite-users@sqlite.org
Subject: Re: [sqlite] Is there any memory leak in the normal routine?
And I watch the the process's run by top.
At first, the memory statistics is:
PID PPID USER STAT VSZ %MEM %CPU COMMAND
17731 15488 root S 1104 5% 7% ./sqlite3multiwrite
When the printf() prints the 150, the memory statistics is:
PID PPID USER STAT VSZ %MEM %CPU COMMAND
17731 15488 root S 1552 5% 7% ./sqlite3multiwrite
It means that after 150 for-cycles, the memory used by sqlite3multiwrite
increase from 1104KB to 1552KB.
What does it mean? memory leak or other thing?
--
View this message in context:
http://old.nabble.com/Is-there-any-memory-leak-in-the-normal-routine--tp28348648p28348725.html
Sent from the SQLite mailing list archive at Nabble.com.
_______________________________________________
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
