View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0020111||Lazarus||FCL||public||2011-08-31 15:28||2011-10-21 14:31|
|Reporter||Daniel J A Bailey||Assigned To||Bart Broersma|
|Status||resolved||Resolution||no change required|
|Summary||0020111: Memory leak on tImage|
|Description||Sorry if this is in the wrong place but a simple test that creates 5000 images in an array and frees them again has shown a memory leak, you don't even need to load an image into it before freeing to see it.|
|Steps To Reproduce||create a simple program that executes this code... (I used lazarus to make a form with a button and onclick event)|
procedure TForm1.Button1Click(Sender: TObject);
var myimages: array of timage;
const ArrayLength = 5000;
for i := 0 to ArrayLength-1 do
myimages[i] := timage.create(form1);
for i := 0 to ArrayLength-1 do
myimages[i].Parent := nil;
|Additional Information||You can simply observe the memory use in the windows task manager, in the process tab make sure the memory column is visible, you will see it go up dramatically and then fall back down, it never goes back to where it started, every time this code runs (every time I click my button) the value goes up. (it's somewhere around 100 bytes)|
|Tags||No tags attached.|
|Fixed in Revision|
||I have only tested this with the 32 bit compiler and the 32 bit IDE on a 64 bit computer running 64 bit windows 7 (I had problems with 64 bit debugging and so won't install it)|
||Sorry, I messed up the additional info in the original report, it's not 100 bytes left from 5000 images, (You may have realised how impossible that is) it's 100k, that's about 20 bytes per image, (this is approximate)|
bug0020111.zip (3,086 bytes)
Compile the program with heaptrc enabled (-gh).
Does it report memory leaks?
There are some discussions about memory usage in Lazarus here: http://lists.lazarus.freepascal.org/pipermail/lazarus/2011-August/065870.html (you'll have to "dig" rather deep into this thread before the memory discussion starts), this may bethe scenario in your case as well.
I can't reproduce it in Win32 (Lazarus latest svn + FPC 2.4.4). Both HeapUsed and VM size (in Task Manager) grow temporally but shrink to a maximum after a few cycles. HeapSize is steady. This can be usually explained by heap fragmentation.
My attached patch isn't actually the best test since the ListBox seem to allocate data that is reflected in Heap values at some point, but using a MessageDlg confirm the data.
Maybe I'll update the with several automated cycles that just stores when and what is the maximum heap ;-)
||Same here on win32. Used the uProcMemMon unit Max Vlasov and myself are developping to trace who consumes memory and the result is that nothing is holding memory. This traces only memory allocated with the fpc memory manager routines. Checked with sysinternals process explorer and peak memory usage remains stable over several cycles. There are no window handles accumulating neither. This is probably a case of the fpc memory manager not returning memory to the OS which is by design. It will return memory when the OS is running low on memory. Use the cmem unit as the first unit in the lpr file and you will see that all memory is returned to the OS.|
I propose to resolve this issue as "no change required", since no memory leak (which original reporter claimed) has been proved.
Discussions on the internals of fpc memory manager can be done on the fpc(-devel) mailinglist.
||Bart, I agree.|
|2011-08-31 15:28||Daniel J A Bailey||New Issue|
|2011-08-31 15:34||Daniel J A Bailey||Note Added: 0051319|
|2011-08-31 15:34||Jonas Maebe||Project||FPC => Lazarus|
|2011-08-31 15:49||Daniel J A Bailey||Note Added: 0051320|
|2011-08-31 18:46||Flávio Etrusco||File Added: bug0020111.zip|
|2011-08-31 18:47||Bart Broersma||LazTarget||=> -|
|2011-08-31 18:47||Bart Broersma||Note Added: 0051328|
|2011-08-31 18:47||Bart Broersma||Status||new => feedback|
|2011-08-31 18:49||Bart Broersma||Severity||crash => minor|
|2011-08-31 18:49||Bart Broersma||Product Version||2.4.2 =>|
|2011-08-31 18:57||Bart Broersma||Note Edited: 0051328|
|2011-08-31 19:02||Flávio Etrusco||Note Added: 0051329|
|2011-08-31 20:43||Ludo Brands||Note Added: 0051331|
|2011-09-28 09:01||Bart Broersma||Note Added: 0052239|
|2011-09-28 10:11||Vincent Snijders||Note Added: 0052240|
|2011-10-21 14:31||Bart Broersma||Status||feedback => resolved|
|2011-10-21 14:31||Bart Broersma||Resolution||open => no change required|
|2011-10-21 14:31||Bart Broersma||Assigned To||=> Bart Broersma|