View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0035684||Lazarus||LCL||public||2019-06-07 14:05||2019-06-24 12:46|
|Product Version||2.0.2||Product Build|
|Target Version||Fixed in Version|
|Summary||0035684: Memory leak on TImageList.GetIcon()|
|Description||Both memory and GDI objects (handles) leaks when icon assigned from TImageList to TImage.|
|Steps To Reproduce||1. 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:
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
|Tags||No tags attached.|
|Fixed in Revision|
GetIconMemleak.zip (69,846 bytes)
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)
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.
@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.
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.
I fixed the type 2 memleak in debugserver.
|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|