Hi folks.

I've got a serious prblem too with debugger and heaptrc. It look like the one described by *Rainer Stratmann *posted last month. My problem goes around the tracing of memory leaks. I've been busy with Martin on the Lazarus mailing list and he couldn't find why addresses were not followed by their line reference. Apparently all tracing references from the program seem to be omitted or maybe better, unreachable.
When I do a strip from the program executable it shrinks from 17 meg down to 2.5 meg. So something is in it.
I can see the memory leak I have generated (read below) but no refecence to the line itself. Instead I receive the reference lines before and after the memory leak creation inside the rtl.
Environment:
W7-win32, Lazarus 1.1 from 2012-06-11, WinCE target added and compiles OK Project:
Very simple project (one form, two buttons one to create a memory leak, one to close)
Redirect heaptrc output to a file
Set compiler options for compiler and linker:
do not use INLINE style C++
-O- omit any optimization
-g automatic debugger
-gl add line numbers
-gh use heaptrc
-WG win32 program
compile, link and run and get this:
/*c:\sources\compiled\TestUib.Exe
Heap dump by heaptrc unit
756 memory blocks allocated : 1539928/1541288
755 memory blocks freed : 1539912/1541272
1 unfreed memory blocks : 16*/ <<======== my block, looks OK /*True heap size : 655360 (96 used in System startup) True free heap : 658416
Should be : 655184
Call trace for block $001D62B0 size 16*/ <<======== my block, looks OK /* $0040D628
$004FAA4E TCONTROL__CLICK, line 2735 of ./include/control.inc $00512A7F TBUTTONCONTROL__CLICK, line 56 of ./include/buttoncontrol.inc $005130B6 TCUSTOMBUTTON__CLICK, line 175 of ./include/buttons.inc $00513711 TBUTTON__CLICK, line 355 of ./include/buttons.inc $005129AA TBUTTONCONTROL__WMDEFAULTCLICKED, line 26 of ./include/buttoncontrol.inc
$0040AE56
$004EDBEF TWINCONTROL__WNDPROC, line 5298 of ./include/wincontrol.inc*/ Thea ddress /*$0040D628*/ corresponds to the function Reallocmem function used to get the memory block

Problem is that I need to debug a complicated package which leaves a lot of memory leaks that I have to trace and correct.

Antonio.

Antonio Fortuny wrote on Wed, 13 Jun 2012:

I can see the memory leak I have generated (read below) but no refecence to the line itself. Instead I receive the reference lines before and after the memory leak creation inside the rtl.

The reason is that the RTL itself is compiled with optimisations. This means that sometimes no stack frame is generated for such routines. As a result, when crawling the stack, you will not see the *caller* of such routines in the stack trace. The only way to work around this is to recompile the RTL without optimisations.

FWIW, the same problem happens with any compiler that implements stack frame optimisations (e.g., with gcc you'd have to use -fno-omit-frame-pointer to prevent this from taking place; the equivalent FPC parameter is -Oonostackframe).

The only solution from a distribution point of view would be to either disable this stack frame optimisation for released units, or to distribute two different RTL's (one compiled with and one compiled without optimisations).

Jonas

Out of interest. I reproduced this myself. And I found that while fpc is omitting some frames, if I run in gdb and step into reallocmem, then gdb is able to show the stack.

So it appears, that it is possible. Though I do not know if GDB does this by analysing the stack only, or gdb also uses knowledge from disassembling the function headers....

Hi all again.

About this boring problem I have maybe a track.
I downloaded the latest Lazarus release (0.9.30 as it is on the main download page from France mirror) and installed it in place of 1.1 It runs FPC 2.6.0
Compile and install needed packages
Compile and run the test project and get the same results: no line tracing information.

Then I changed the test as suggested by Martin on the Lazarus mailing list and used a TStringList which is never freed.
This time it woks !!! =-O
I did not experience all possible combinations of debug switches I will try now to change the package I must test and include some "smart" memory leaks.
I'll notice the results on the list

Antonio.