Hi all.

I'm running in trouble again when using "heaptrc" to trace memeory leaks. Win64, Lazarus 0.9.31-35571, FPC 2.6.1
Project options set:
code generation all standard
linking:

I have deliberately allocated one memory block of 16 bytes that is not released (shown in heaptrc report)
I have redirected the heaptrc output to a file, at the very beginning of the program:
project.lpr:
{$IFDEF MEMORY_LEAKS}

   MLFile := ChangeFileExt(ParamStr(0), '.mlk');
   if FileExists(MLFile) then
     DeleteFile(MLFile);
   SetHeapTraceOutput(MLFile);

{$ENDIF}
and I get an heptrc report which contains:
C:\Sources\compiled\LazArraysUIB.exe
Heap dump by heaptrc unit
9455 memory blocks allocated : 4020987/4035768
9454 memory blocks freed : 4020971/4035752
1 unfreed memory blocks : 16 <<=========================== sounds OK True heap size : 786432 (160 used in System startup) True free heap : 813088
Should be : 786128
Call trace for block $0000000000086ED0 size 16
<<========================== this is OK
$000000000040FE8E
$0000000000540A19
$0000000000531EF9
$000000000050E44A
$0000000000586FA9
$000000000052DC99
$000000000053B4C7
$00000000005B5237
Where are gone the line references ?

Any ideas ?
BTW, same behaviour with Lazarus Win32 1.1-37027 FPC 2.6.1 on a Vista Win32

Antonio.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120607/22ae7bec/attachment-0001.html> -------------- next part --------------
A non-text attachment was scrubbed...
Name: fhjbabid.png
Type: image/png
Size: 15284 bytes
Desc: not available
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120607/22ae7bec/attachment-0001.png>

Have you enabled "Display line numbers in ..." in the compiler options of your project?

Mattias

Mattias Gaertner wrote

Have you enabled "Display line numbers in ..." in the compiler options of your project?

According to his screenshot in his first post he has.

Bart

Le 07/06/2012 11:09, Mattias Gaertner a ?crit :

Check the window attached to my original message: YES (linker option)

Is lazarus compiled with dwarf? Mixing dwarf and stabs is not working properly on windows: http://bugs.freepascal.org/view.php?id=20344

Ludo

Maybe the very first address is somewhere without debug info? The problem is that the stackdump permamently stops resolving, once this happens.

Since you are on 1.1
please install the package LeakView - then go to tools menu and open the leak view window
load the data.

there is a button "resolve". select the exe that leaked. it is a new feature. it SHOULD resolve any address for which symbols exist -------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120607/fea721fe/attachment.html>

Le 07/06/2012 22:50, Martin a ?crit :

Maybe. But in any case, the very last is inside the program:
procedure TForm1.BtnConnectClick(Sender: TObject);
var
   pc: PChar;
begin
*/  pc := nil;
   ReAllocMem(pc, 16);
/*  ConnectDB;
   BtnConnect.Enabled := False;
   BtnDisconnect.Enabled := not BtnConnect.Enabled;
   BtnConnect.Enabled := False;
   GrQuery.Enabled := True;
   GrSerialTest.Enabled := True;
   GrSmallTests.Enabled := True;
   AllowQueryButtons(False);
end;

The problem is that the stackdump permamently stops resolving, once this happens. Since you are on 1.1

yes in Vista WIN32 but not in my current development platform: Windows server 2003 x64
Lararus 0.9.31.

please install the package LeakView - then go to tools menu and open the leak view window load the data

I've installedthe package leakview but it does not help really:

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120608/e2dbcc68/attachment-0001.html> -------------- next part --------------
A non-text attachment was scrubbed...
Name: jffhgdfj.png
Type: image/png
Size: 6873 bytes
Desc: not available
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120608/e2dbcc68/attachment-0001.png>

the "resolve" button only exists in 1.1

so in 0.9.31 or before leak view does not help.

The resolve button SHOULD try to lookup the addresse. But it is new and not well tested yet.

It must have the same exe that produced the addresses. Using an equal exe compiled on another computer will give WRONG results. And the exe must have debug info.

the only difference the "resolve" button does continue after unresolve able addresses. and it may handle mixed stabs/dwarf (not tested) -------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120608/44739b0d/attachment.html>

2012/6/8 Martin :

The problem is that the stackdump permamently stops resolving, once this happens.

Can't this be fixed in FPC? This sounds like a bug to me.

But it does not really :-\

I've prepared a new virtual machine with W7-Win32
Lazarus full 1.1 from 2012-06-11 + WinCE for cross-compile Made a 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:
-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 */the result whether I use -gs or -g. I can easily guess that both blank lines with only an address are the two lines of my project I've installed leakview but the Resolve button resolves anything with the project.exe
Thea ddress /*$0040D628*/ corresponds to the function Reallocmem function used to get the memory block

Antonio
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120612/71c7b958/attachment.html>

can you try

gdb.exe /*c:\sources\compiled\TestUib.Exe*/

info line *0x0040D628

The whole thing is rather odd. From what you described, you done the correct steps. And it works, if I do it here (vista 32 bit). Though I use the released fpc 2.6.0 (that may still be an idea)

I can only see 2 reasons.
1) For some reason, fpc did not write or link symbol info for your unit.
2) The stabs reader in fpc has problems reading it ("resolve" uses the same reader)

In case 2 gdb should be able to read it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120612/30a30633/attachment.html>

(gdb) info line *0x0040D628
No line number information available for address
0x40d628 <SYSTEM_REALLOCMEM$POINTER$LONGWORD$$POINTER+8> (gdb)

The whole thing is rather odd. From what you described, you done the correct steps. And it works, if I do it here (vista 32 bit). Though I use the released fpc 2.6.0 (that may still be an idea)

OK. I'll try tomorrow morning in place of 2.6.1

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120612/aea10114/attachment.html>

Ok, so that address is in the unit System from the RTL (fpc)

The RTL has no line-info. So it can not be resolved. You can recompile it, but that wouldn't solve the problem. Because, then there would be the line in the System unit in the trace, and still not your code.

/*Call trace for block $001D62B0 size 16*/ <<======== my block, looks OK /* $0040D628 <<line ?? in unit System>>
$004FAA4E TCONTROL__CLICK, line 2735 of ./include/control.inc */
Now that means there is no entry for your TForm1.Button1Clicked procedure....

I can only guess: The compiler inlined the ReAllocMem into your Button1Clicked .
So the frame is Button1Clicked, but the Address is not.

Did you compile wit optimization -O ? OR otherwise enabled inlining? Please try with -O0 (letter O, then zerro).

Better yet in the "Project Options" dialog go to "Compiler Opts" / "Other" and in the field "Custom Options" enter:
-O-

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120612/96aae3b1/attachment.html>

Now that means there is no entry for your TForm1.Button1Clicked procedure....

That's what I reasonably suspect

I can only guess: The compiler inlined the ReAllocMem into your Button1Clicked . So the frame is Button1Clicked, but the Address is not.

This could have been an explanation: Inline whas checked in project options

That's what I did:
- make a new project (to get rid of all annoyances of the original)
- disable optimization
- disable Inline style C++
- remove the generated form and add the main unit
- set debugger standard (-g)
- use heaptrc

still the same: rtl is traced but nothing for the program: begins to be annoying
I have a lab with the W7-Win32. Any ideas to could have (except re-installing Win, of course ;-) ) I can implement. I really need a solution.

Antonio.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120613/22114a88/attachment-0001.html>

Ok, I can reproduce it. And that means your settings and all are ok. However I do not have a solution. Best to ask on the fpc mailinglist.

This is what I found.
- It only happens with "reallocmem" (probably other similar commands)
- It works fine, if you create a leak as follows "TObject.Create;" (and never free it)

Reallocmem is NOT inlined

But, from looking at the assembler code, it seems that it does not setup a stackframe as other code does. I **guess** the stuck dumpng code has a problem with this minimal frame.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120613/3e2b770f/attachment.html>

2012/6/13 Martin :

But, from looking at the assembler code, it seems that it does not setup a stackframe as other code does. I **guess** the stuck dumpng code has a problem with this minimal frame.

If it omits the stackframe then something (probably the RTL) was compiled with optimizations turned on. I can reproduce it too with default settings but here are three simple steps how to get a complete backtrace:

* build FPC (including all of RTL) with
make clean all OPT="-O- -gl"
and then install it to where it belongs in your setup, make sure Lazarus will use it.

* put this into the "configure build Lazarus" -> "Options" field (at the end of the line)
-O- -g1

* uncheck all optimizations in your project, check the -gl option.

Then compile your project. The very first compile will take a while because it will now automatically also rebuild all LCL with the new compiler and the new settings, then start your application, here is what I get (previously I got the same output like already posted, now I get this):

bernd at t40:~/Desktop/testus\ $ ./project1
Heap dump by heaptrc unit
1204 memory blocks allocated : 1569116/1572328
1203 memory blocks freed : 1569100/1572312
1 unfreed memory blocks : 16
True heap size : 622592
True free heap : 625744
Should be : 622512
Call trace for block $B77AE6A0 size 16
$0807391A REALLOCMEM, line 317 of
/home/bernd/lazsvn/fixes_2_6/rtl/inc/heap.inc
$08099450 TFORM1__BUTTON1CLICK, line 37 of unit1.pas $081F822E TCONTROL__CLICK, line 2734 of ./include/control.inc $0821E2AF TBUTTONCONTROL__CLICK, line 56 of ./include/buttoncontrol.inc $0821EA06 TCUSTOMBUTTON__CLICK, line 175 of ./include/buttons.inc $0821F061 TBUTTON__CLICK, line 355 of ./include/buttons.inc $0821E1DA TBUTTONCONTROL__WMDEFAULTCLICKED, line 26 of ./include/buttoncontrol.inc
$0806E77D TOBJECT__DISPATCH, line 592 of
/home/bernd/lazsvn/fixes_2_6/rtl/inc/objpas.inc

It seems (and this was new to me too) that -O1 is not enough to stop it from optimizing the stack frames, it really must be -O- (I always thought this only happens in O2 or higher but it happens in O1 already).

2012/6/13 Bernd :

-O- -g1

of cours this must be
-O- -gl

The interesting point is, that if I step into reallocmem, GDB can display the correct stackframe.

But FPC skips one frame. And the strange thing is: FPC includes the frame (the address in the frame) that does not have the full stackframe code (push... / leave). But it excludes the frame that called this optimised frame.