Forum > Debugger

Needed advice to debug leaks shown only after switching to new Laz&FPC

<< < (2/2)

Remy Lebeau:

--- Quote from: Thaddy on December 11, 2017, 03:23:30 pm ---I recall Indy has some expected memory leaks registered (at least under Delphi)

--- End quote ---

That is correct.  The 3 leaks in the above report are from Indy.

The IdThread unit has a global TIdThreadSafeInteger object, which has an internal TCriticalSection object.

The IdStack unit has a global TCriticalSection object.

These two global objects are intentionally leaked by default, but the leaks can be disabled by re-compiling Indy with FREE_ON_FINAL enabled (but do read the warnings documented at the very bottom of those units' source code).

In Delphi, these 3 leaks are registered with the memory manager so they do not appear in leak reports.  FreePascal does not have that option in the HeapTrc unit (see this discussion).

avra:

--- Quote from: Remy Lebeau on December 11, 2017, 09:24:16 pm ---The 3 leaks in the above report are from Indy.
...
These two global objects are intentionally leaked by default, but the leaks can be disabled by re-compiling Indy with FREE_ON_FINAL enabled (but do read the warnings documented at the very bottom of those units' source code).
--- End quote ---
It would really be nice if this knowledge ends up in a wiki: http://wiki.freepascal.org/Indy_with_Lazarus. If no one else with more knowledge of the issue wants to do it, I will.
 ::)

avra:

--- Quote ---It would really be nice if this knowledge ends up in a wiki
--- End quote ---
Here it is. Please review and correct if needed.
http://wiki.lazarus.freepascal.org/Indy_with_Lazarus#Memory_leaking_issue

btw1. In last 2 weeks my application was running 24/7 and I was lucky to have one network down event and several oracle server down events. Exceptions are logged and properly handled so on application exit there were no leaks. Problem definitely solved!

btw2. If anyone is interested, I have contributed thread safe TMemoChannel to MultiLog and assisted author with making MultiLog fully thread safe. All communication threads from my mentioned application log data to the same log file and to the same Memo component without problems. I am not aware of any other logging library that can do this at the moment.
 :D ;) :D

Thaddy:
Remy, Avra,

The leaks may disappear if you wrap the leaking classes in something like my smartpointer code I borrowed from an idea by Marco Cantu:
http://forum.lazarus.freepascal.org/index.php/topic,33095.msg221076.html#msg221076
http://forum.lazarus.freepascal.org/index.php/topic,37524.msg252382.html#msg252382

Until smartpointers are implemented as standard, that is. Threadsafe.

Note my code is cross-platform and tested on nixes (arm too...) and win32/64.
E.g.:

--- Code: Pascal  [+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i < x.length; i++) { x[i].style.maxHeight='none'; x[i].style.height = Math.min(x[i].clientHeight+15,306)+'px'; x[i].style.resize = "vertical";}};} ---program smartpointersCS;{$ifdef fpc}{$mode delphi}{$endif}uses  classes,smartptrs,SyncObjs;var  L:TCriticalSection;  PL:Auto<TCriticalSection>;begin  // Auto create  L:= PL.Value;  L.Acquire; try ... worker.  finally   L.Release; end;  // Auto cleanupend.
This uses the smartptrs unit from the second link.

Remy Lebeau:

--- Quote from: Thaddy on December 26, 2017, 05:46:47 pm ---The leaks may disappear if you wrap the leaking classes in something like my smartpointer code I borrowed from an idea by Marco Cantu:
http://forum.lazarus.freepascal.org/index.php/topic,33095.msg221076.html#msg221076
http://forum.lazarus.freepascal.org/index.php/topic,37524.msg252382.html#msg252382

--- End quote ---

The leaks are not a matter of not being able to free the objects (obviously, they can be, as seen when FREE_ON_FINAL is defined), but more a matter of unit dependency.  The objects in question are shared with other units, and it has been noticed that sometimes units may not always be finalized in the order you are expecting, and that has been observed in the wild.  So rather than freeing these objects by default, they are leaked instead, in case they are still accessed later.  The leak is minor (only a few bytes), and only during unit finalization, which 9x% of the time will only be during app shutdown (unless you are using Indy in a DLL that gets unloaded dynamically during runtime).

Navigation

[0] Message Index

[*] Previous page

Go to full version