View Issue Details

IDProjectCategoryView StatusLast Update
0035684LazarusLCLpublic2019-06-24 12:46
ReporterserbodAssigned To 
PrioritynormalSeverityminorReproducibilityalways
Status newResolutionopen 
Platformx86_64OSWindowsOS Version7
Product Version2.0.2Product Build 
Target VersionFixed in Version 
Summary0035684: Memory leak on TImageList.GetIcon()
DescriptionBoth memory and GDI objects (handles) leaks when icon assigned from TImageList to TImage.
Steps To Reproduce1. Create application with visual form
2. Add TImage
3. Add TImageList with 2 icons
3. Add TTimer with Interval=1
4. In OnTimer put code:
====
  ImageList1.GetIcon(Image1.Tag, Image1.Picture.Icon);
  Image1.Tag := Image1.Tag + 1;
  if Image1.Tag >= 2 then Image1.Tag := 0;
====
5. Run program and look at resource counters in system task manager
TagsNo tags attached.
Fixed in Revision
LazTarget
WidgetsetWin32/Win64
Attached Files
  • GetIconMemleak.zip (69,846 bytes)
  • imglist.inc.patch (446 bytes)
    Index: lcl/include/imglist.inc
    ===================================================================
    --- lcl/include/imglist.inc	(revision 60715)
    +++ lcl/include/imglist.inc	(working copy)
    @@ -580,6 +580,8 @@
         ListImg.Free;
       end;
       Image.Handle := CreateIconIndirect(@IconInfo);
    +  if IconInfo.hbmColor<>0 then DeleteObject(IconInfo.hbmColor);
    +  if IconInfo.hbmMask<>0  then DeleteObject(IconInfo.hbmMask);
     
       RawImg.FreeData;
     end;
    
    imglist.inc.patch (446 bytes)

Activities

serbod

2019-06-07 14:10

reporter   ~0116604

Sample project

GetIconMemleak.zip (69,846 bytes)

BrunoK

2019-06-10 19:41

reporter   ~0116662

Last edited: 2019-06-10 19:42

View 2 revisions

Possible patch (maybe similar problem as 0028577 that has been resolved).

Seems to work ok, No more GDI rising.

Issue 0029901 also leaks GDI resources on Windows, patch seems to clear that too.



imglist.inc.patch (446 bytes)
Index: lcl/include/imglist.inc
===================================================================
--- lcl/include/imglist.inc	(revision 60715)
+++ lcl/include/imglist.inc	(working copy)
@@ -580,6 +580,8 @@
     ListImg.Free;
   end;
   Image.Handle := CreateIconIndirect(@IconInfo);
+  if IconInfo.hbmColor<>0 then DeleteObject(IconInfo.hbmColor);
+  if IconInfo.hbmMask<>0  then DeleteObject(IconInfo.hbmMask);
 
   RawImg.FreeData;
 end;
imglist.inc.patch (446 bytes)

jamie philbrook

2019-06-11 22:54

reporter   ~0116679

I just ran the test app without the "imglist.inc.patch and there is no leak on my end.
However, I did fix the "LoadFromRawImage" method which was leaking and did cause a few gdi controls
to leak memory..
  And this is with laz 2.0.2 but a slightly fixed version, not the one on the down load..
  The Trunk should have this fix too.

BrunoK

2019-06-12 10:30

reporter   ~0116685

@jamie philbrook 2019-06-11 22:54
The leak reported here is not detectable with heaptrc. It is not related to issue 0035372.

Original serbod's report is about :
5. Run program and look at resource counters in SYSTEM TASK MANAGER.
GDI objects, in Windows, are allocated in Process memory but not thru the FPC heap manager.
See https://blogs.msdn.microsoft.com/dsui_team/2013/04/23/debugging-a-gdi-resource-leak.

I did know about 3 potential source of leaks these were :

In FPC(3.0.4)/Lazarus applications there are 2 types of user leaks :
1 - Allocated but non free'd TOBject.Create / GetMem, these are catched by heaptrc.
2 - Invisible usage leaks. Those are TComponent descendants that are created multiple times but actually use only the last created instance. An example is .\laztools\debugserver\frmmain.pp that does in TMainForm.ShowOptions TOptionsForm.Create+ShowModal. The TOptionsForm instance is not freed after showmodal so every time you call the ShowOptions you have one more instance allocated.
There will be no memory leak reported because when the TMainForm instance is freed all its components, including all additional TOptionsForm instances, will be freed.

3 - In FPC(3.0.4) I detected one compiler generated code leak (in the compiler itself) regarding const ansistring function parameters. I couldn't generate a simple demonstration for that, so I didn't report it.

Now a new possibility of leaks in Program memory space is added to the list :
4 - Forgetting to release GDI objects after use.

Michael Van Canneyt

2019-06-24 12:46

administrator   ~0116887

@BrunoK:
I fixed the type 2 memleak in debugserver.

Issue History

Date Modified Username Field Change
2019-06-07 14:05 serbod New Issue
2019-06-07 14:10 serbod File Added: GetIconMemleak.zip
2019-06-07 14:10 serbod Note Added: 0116604
2019-06-10 19:41 BrunoK File Added: imglist.inc.patch
2019-06-10 19:41 BrunoK Note Added: 0116662
2019-06-10 19:42 BrunoK Note Edited: 0116662 View Revisions
2019-06-11 22:54 jamie philbrook Note Added: 0116679
2019-06-12 10:30 BrunoK Note Added: 0116685
2019-06-24 12:46 Michael Van Canneyt Note Added: 0116887