Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / lazarus / 2010-04

mem leak with easy dock manager

6 messages · 2 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Martin

Adding EasyDock manager to Lazarus, I get the below memory leaks (with both fpc 2.4.0 and 2.5.1)

Heap dump by heaptrc unit
576782 memory blocks allocated : 83129212/84721448 576772 memory blocks freed : 83119804/84712024 10 unfreed memory blocks : 9408
True heap size : 1507328 (176 used in System startup) True free heap : 1841600
Should be : 1497088
Call trace for block $00270B18 size 400
$0040EA48 line 303 of ../inc/heap.inc
$00512116 line 3053 of intfgraphics.pas
$005128A3 line 3155 of intfgraphics.pas
$0050DB48 line 1335 of intfgraphics.pas
$0051B1F0 line 5601 of intfgraphics.pas
$00542401 line 811 of src/fpreadpng.pp
$0051B287 line 5621 of intfgraphics.pas
$00504606 line 230 of src/fphandler.inc
Call trace for block $0B7018D0 size 4096
$0040EA48 line 303 of ../inc/heap.inc
$004CBCD4 line 423 of include/rasterimage.inc
$004C571B line 1947 of graphics.pp
$004C5826 line 1966 of graphics.pp
$004C57BD line 1957 of graphics.pp
$00B18322
$00B1C0B2
$0040E1A4 line 757 of ../inc/system.inc
Call trace for block $0B6FF728 size 20
$004CBDCF line 442 of include/rasterimage.inc
$004CBCD4 line 423 of include/rasterimage.inc
$004C571B line 1947 of graphics.pp
$004C5826 line 1966 of graphics.pp
$004C57BD line 1957 of graphics.pp
$00B18322
$00B1C0B2
$0040E1A4 line 757 of ../inc/system.inc
Call trace for block $0B6D0280 size 124
$004CB6E7 line 283 of include/rasterimage.inc
$004CDE3D line 50 of include/custombitmap.inc
$004C56CD line 1945 of graphics.pp
$004C5826 line 1966 of graphics.pp
$004C57BD line 1957 of graphics.pp
$00B18322
$00B1C0B2
$0040E1A4 line 757 of ../inc/system.inc
Call trace for block $001C8E70 size 64
$004C56CD line 1945 of graphics.pp
$004C5826 line 1966 of graphics.pp
$004C57BD line 1957 of graphics.pp
$00B18322
$00B1C0B2
$0040E1A4 line 757 of ../inc/system.inc
$00412481 line 376 of system.pp
$004C57BD line 1957 of graphics.pp
Call trace for block $00270938 size 400
$0040EA48 line 303 of ../inc/heap.inc
$00512116 line 3053 of intfgraphics.pas
$005128A3 line 3155 of intfgraphics.pas
$0050DB48 line 1335 of intfgraphics.pas
$0051B1F0 line 5601 of intfgraphics.pas
$00542401 line 811 of src/fpreadpng.pp
$0051B287 line 5621 of intfgraphics.pas
$00504606 line 230 of src/fphandler.inc
Call trace for block $0B700880 size 4096
$0040EA48 line 303 of ../inc/heap.inc
$004CBCD4 line 423 of include/rasterimage.inc
$004C571B line 1947 of graphics.pp
$004C5826 line 1966 of graphics.pp
$004C57BD line 1957 of graphics.pp
$00B18322
$00B1C0B2
$0040E1A4 line 757 of ../inc/system.inc

Reply by email

Hans-Peter Diettrich
to Martin
Adding EasyDock manager to Lazarus, I get the below memory leaks (with both fpc 2.4.0 and 2.5.1)

I removed the image destruction a while ago, to prevent other errors.

DoDi

Reply by email

Martin
to Hans-Peter Diettrich
Hans-Peter Diettrich wrote 6 lines
Martin schrieb: > Adding EasyDock manager to Lazarus, I get the below memory leaks > (with both fpc 2.4.0 and 2.5.1) I removed the image destruction a while ago, to prevent other errors.

And that means?
Because the above sounds like "it's an intentional leak"? And I would not want to believe that.

Martin

Reply by email

Hans-Peter Diettrich
to Martin
Show quoted text 6 lines
>> Adding EasyDock manager to Lazarus, I get the below memory leaks >> (with both fpc 2.4.0 and 2.5.1) > > I removed the image destruction a while ago, to prevent other errors. And that means?

This way the app doesn't AV on exit.

Because the above sounds like "it's an intentional leak"? And I would not want to believe that.

I could not make it work better - see the related comments in EasyDockSite.DestroyDockHeaderImages.

There exist more docking-related bugs in the LCL and widgetsets, see the LCL TODO list at the begin of EasyDockSite. Since a few weeks another bug should be added to this list, since the Win32 widgetset does no more properly return the BoundsRect of an undocked form.

DoDi

Reply by email

Martin
to Hans-Peter Diettrich
Hans-Peter Diettrich wrote 17 lines
Martin schrieb: >>> Adding EasyDock manager to Lazarus, I get the below memory leaks >>> (with both fpc 2.4.0 and 2.5.1) >> >> I removed the image destruction a while ago, to prevent other errors. > > And that means? I could not make it work better - see the related comments in EasyDockSite.DestroyDockHeaderImages. There exist more docking-related bugs in the LCL and widgetsets, see the LCL TODO list at the begin of EasyDockSite. Since a few weeks another bug should be added to this list, since the Win32 widgetset does no more properly return the BoundsRect of an undocked form.

Ok, I see,
I don't know LCL good enough.

but 2 ideas that may or may not help.

If you know the unit in which the handles (the missing of which causes the crash) are destroyed, then add it to the uses (interface section) clause.
My understanding is that a unit's intialization, should be called after the initalization of all used units.
For finalization, imho it should be the other way round; your unit should come first.

If not, or maybe easier, can those images not be destroyed by a component which is owned by application (and therefore gets freed at that time)?

Martin

Reply by email

Hans-Peter Diettrich
to Martin
>>>> Adding EasyDock manager to Lazarus, I get the below memory leaks >>>> (with both fpc 2.4.0 and 2.5.1) >>> >>> I removed the image destruction a while ago, to prevent other errors.

Just checked, the problem seems to have gone away. Destruction now again is enabled.

My understanding is that a unit's intialization, should be called after the initalization of all used units.

This is where problems (SIGILL) now prevent the start of some docking samples :-(
I'll try to find out more.

DoDi

Reply by email