View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0020417||Lazarus||LCL||public||2011-10-05 11:59||2011-10-22 21:50|
|Reporter||Alexei Rossiev||Assigned To||Zeljan Rikalo|
|Product Version||0.9.31 (SVN)|
|Summary||0020417: Memory leak when the bitmap drawing: Lazarus rev. 30135 and later (fpc 2.5.1, Ubuntu 10.04)|
|Description||I discovered a memory leak when multiple drawing the button with a bitmap.|
Run the attached project and click Start.
And run the System Monitor: TestBug and Xorg processes.
|Tags||No tags attached.|
|Fixed in Revision||33032|
TestBug.tar.gz (4,118 bytes)
Does heaptrace say there is a leak (Project -> Project Options -> Lining -> Use heaptrace unit (-gh))?
You might just be seeing the same as discussed in issue 0020111
The memory in the fpc memory manager migth get fragmented, which explains the growht in memeory usage, but the real question is does fpc give all memory back to the OS at program end (hence my question about hepatrace)
0 unfreed memory blocks: 0
Unfortunately, the memory leak is not only the program itself, but also in the process "xorg", which would then not be returned. After some time, this leads to a system crash.
Thus, the program can not run for a long time, which is very critical.
TImage uses the TBitmap in his work, so, obviously, these problems are a common cause.
But there are different operating systems.
I found where the leak!
Variable MskBitmap is created but is not freed after.
Please, fix it!
||I was running your test app for a long time and din't see any problem.|
The code does indeed have a leak (if SrcDevContext.CurrentBitmap can ever be nil) - or useless and bad code otherwise.
I would assume that SrcDevContext.CurrentBitmap could be available or not depending on several system conditions (gtk version, screen color depth, xserver driver, composition manager, local vs remote, and more).
I guess the easiest fix is to invoke g_object_ref when assigning TempMaskBitmap to MskBitmap and g_object_unref on the exit points.
Also, this is one of the first hits in Google: http://osdir.com/ml/svn-commits-list/2009-07/msg01837.html. We should probably change those.
Yeah, heap grows to infinity. Such app will be killed by root in few hours, because it'll exhaust complete memory.
Look heap after 5 minutes, it grows by 4kb for each timer tick (in example).
Tested qt version too, and heap is correct, no wild growing.
Process 4987 - TestBug
The process TestBug (with pid 4987) is using approximately 8.1 MB of memory.
It is using 7.4 MB privately, 5.1 KB for pixmaps, and a further 6.6 MB that is, or could be, shared with other programs.
Dividing up the shared memory between all the processes sharing that memory we get a reduced shared memory usage of 681.0 KB. Adding that to the private and pixmap usage, we get the above mentioned total memory footprint of 8.1 MB.
The memory usage of a process is found by adding up the memory usage of each of its libraries, plus the process's own heap, stack and any other mappings.
5504 KB [heap]
1792 KB /home/zeljko/brisime/20417/TestBug/TestBug
48 KB [stack]
12 KB /lib/libgio-2.0.so.0.2600.0
12 KB /lib/libc-2.13.so
1396 KB /usr/lib/libgtk-x11-2.0.so.0.2200.0
572 KB /lib/libc-2.13.so
524 KB /usr/lib/libgdk-x11-2.0.so.0.2200.0
444 KB /lib/libglib-2.0.so.0.2600.0
400 KB /usr/lib/libX11.so.6.3.0
Pixmap 5 KB (Might be stored in the graphics card's memory)
Private 7604 KB (= 1676 KB clean + 5928 KB dirty)
Shared 6776 KB (= 6704 KB clean + 72 KB dirty)
Rss 14380 KB (= Private + Shared)
Pss 8285 KB (= Private + Shared/Number of Processes)
Swap 0 KB
||Please test and close if ok.|
|2011-10-05 11:59||Alexei Rossiev||New Issue|
|2011-10-05 11:59||Alexei Rossiev||File Added: TestBug.tar.gz|
|2011-10-05 11:59||Alexei Rossiev||Widgetset||=> GTK 2|
|2011-10-05 15:07||Bart Broersma||LazTarget||=> -|
|2011-10-05 15:07||Bart Broersma||Note Added: 0052558|
|2011-10-05 15:07||Bart Broersma||Status||new => feedback|
|2011-10-05 15:08||Bart Broersma||Note Edited: 0052558|
|2011-10-05 15:49||Alexei Rossiev||Note Added: 0052570|
|2011-10-05 15:52||Alexei Rossiev||Note Edited: 0052570|
|2011-10-05 15:54||Alexei Rossiev||Note Edited: 0052570|
|2011-10-07 09:27||Alexei Rossiev||Note Added: 0052709|
|2011-10-07 13:12||Vincent Snijders||Relationship added||has duplicate 0020430|
|2011-10-07 13:14||Vincent Snijders||LazTarget||- => 0.99.0|
|2011-10-07 13:14||Vincent Snijders||Status||feedback => acknowledged|
|2011-10-07 13:14||Vincent Snijders||Target Version||=> 0.99.0|
|2011-10-08 16:53||Juha Manninen||Note Added: 0052779|
|2011-10-08 19:39||Flávio Etrusco||Note Added: 0052784|
|2011-10-08 20:15||Flávio Etrusco||Note Edited: 0052784|
|2011-10-08 20:17||Flávio Etrusco||Note Edited: 0052784|
|2011-10-22 21:24||Zeljan Rikalo||Note Added: 0053299|
|2011-10-22 21:24||Zeljan Rikalo||Status||acknowledged => confirmed|
|2011-10-22 21:36||Zeljan Rikalo||Status||confirmed => assigned|
|2011-10-22 21:36||Zeljan Rikalo||Assigned To||=> Zeljan Rikalo|
|2011-10-22 21:50||Zeljan Rikalo||Fixed in Revision||=> 33032|
|2011-10-22 21:50||Zeljan Rikalo||Status||assigned => resolved|
|2011-10-22 21:50||Zeljan Rikalo||Resolution||open => fixed|
|2011-10-22 21:50||Zeljan Rikalo||Note Added: 0053301|