View Issue Details

IDProjectCategoryView StatusLast Update
0020111LazarusFCLpublic2011-10-21 14:31
ReporterDaniel J A Bailey Assigned ToBart Broersma  
PrioritynormalSeverityminorReproducibilityalways
Status resolvedResolutionno change required 
Platformi386OSWindows 
Summary0020111: Memory leak on tImage
DescriptionSorry 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 Reproducecreate 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;
  i: integer;
const ArrayLength = 5000;
begin
 setLength(myimages, ArrayLength);
 for i := 0 to ArrayLength-1 do
 begin
   myimages[i] := timage.create(form1);
 end;

 for i := 0 to ArrayLength-1 do
 begin
   myimages[i].Parent := nil;
   myImages[i].Free;
 end;
end;
Additional InformationYou 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)
TagsNo tags attached.
Fixed in Revision
LazTarget-
Widgetset
Attached Files

Activities

Daniel J A Bailey

2011-08-31 15:34

reporter   ~0051319

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)

Daniel J A Bailey

2011-08-31 15:49

reporter   ~0051320

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)

2011-08-31 18:46

 

bug0020111.zip (3,086 bytes)

Bart Broersma

2011-08-31 18:47

developer   ~0051328

Last edited: 2011-08-31 18:57

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.

Flávio Etrusco

2011-08-31 19:02

developer   ~0051329

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 ;-)

Ludo Brands

2011-08-31 20:43

developer   ~0051331

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.

Bart Broersma

2011-09-28 09:01

developer   ~0052239

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.

Vincent Snijders

2011-09-28 10:11

manager   ~0052240

Bart, I agree.

Issue History

Date Modified Username Field Change
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