Sign in Join

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

Mailing lists / fpc-pascal / 2008-11

Help with understanding HeapTrc output

6 messages · 4 people · –

Reply by email Subscribe to this list Your subscription

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

Graeme Geldenhuys

Sorry, but I know the output below is going to wrap horribly. I'm self-taught when it comes to understanding the heaptrc output. I also couldn't find clear documentation explaining the output.

From the information below, I gathered the following information. But

a few points I'm not sure about...

1) Every "Call trace for block" is a memory leak, correct?

2) Each "Call trace for block" is where the memory was allocated (start being used)?

3) I should trace the information from the bottom line to the top line...

4) Why does it quote more than one line? If I allocated memory on a specific line, should just that line be quoted?

----------------------------------
Heap dump by heaptrc unit
43868 memory blocks allocated : 3458694/3643528
43800 memory blocks freed : 3456984/3641616
68 unfreed memory blocks : 1710
True heap size : 950272
True free heap : 943984
Should be : 944552
Call trace for block $B6F99188 size 48
$080AD78F MAINPROC, line 104 of tutoradmin.lpr
$080B6127 MAINPROC, line 104 of tutoradmin.lpr
$0809849B TCUSTOMLISTMEDIATOR__CREATESUBMEDIATORS, line 1122 of /home/graemeg/programming/3rdParty/tiOPF2/Source/Core/tiBaseMediator.pas $0809BECC TSTRINGGRIDMEDIATOR__REBUILDLIST, line 497 of ./gui/tiListMediators.pas
$080988F8 TCUSTOMLISTMEDIATOR__UPDATE, line 1195 of /home/graemeg/programming/3rdParty/tiOPF2/Source/Core/tiBaseMediator.pas $080618DE TTIOBJECT__NOTIFYOBSERVERS, line 3941 of /home/graemeg/programming/3rdParty/tiOPF2/Source/Core/tiObject.pas $0806185F TTIOBJECT__NOTIFYOBSERVERS, line 3926 of /home/graemeg/programming/3rdParty/tiOPF2/Source/Core/tiObject.pas $08096218 TMEDIATORVIEW__SETACTIVE, line 500 of
/home/graemeg/programming/3rdParty/tiOPF2/Source/Core/tiBaseMediator.pas Call trace for block $B6F95718 size 16
$080AC422 MAINPROC, line 104 of tutoradmin.lpr
$080B2577 MAINPROC, line 104 of tutoradmin.lpr
$08130EC8 TTRANSACTIONDISPLAY__CREATECUSTOM, line 83 of transactiondisplay.pas
$08098737 TCUSTOMLISTMEDIATOR__CREATE, line 1164 of /home/graemeg/programming/3rdParty/tiOPF2/Source/Core/tiBaseMediator.pas $0809C5BA TPROPERTYLINKDEF__CREATEMEDIATOR, line 188 of /home/graemeg/programming/3rdParty/tiOPF2/Source/Core/tiFormMediator.pas $0809C97E TFORMMEDIATOR__CREATEMEDIATORS, line 285 of /home/graemeg/programming/3rdParty/tiOPF2/Source/Core/tiFormMediator.pas $0809CA09 TFORMMEDIATOR__BIND, line 299 of
/home/graemeg/programming/3rdParty/tiOPF2/Source/Core/tiFormMediator.pas $0809C7F0 TFORMMEDIATOR__SETACTIVE, line 247 of
/home/graemeg/programming/3rdParty/tiOPF2/Source/Core/tiFormMediator.pas ----------------------------------

Regards,
- Graeme -

Jonas Maebe
to Graeme Geldenhuys
Graeme Geldenhuys wrote
1) Every "Call trace for block" is a memory leak, correct?

Yes.

2) Each "Call trace for block" is where the memory was allocated (start being used)?

Allocated.

3) I should trace the information from the bottom line to the top line...

It's a backtrace, like when an exception or run time error occurs. The top line is the actual place where the allocation happened, the next is the caller of that place, etc.

4) Why does it quote more than one line? If I allocated memory on a specific line, should just that line be quoted?

I don't understand what you mean with "quote more than one line". However, things like this:

Show quoted text 5 lines
$080AD78F MAINPROC, line 104 of tutoradmin.lpr $080B6127 MAINPROC, line 104 of tutoradmin.lpr $0809849B TCUSTOMLISTMEDIATOR__CREATESUBMEDIATORS, line 1122 of /home/graemeg/programming/3rdParty/tiOPF2/Source/Core/ tiBaseMediator.pas

usually mean that no line (debug) information was available for the two first addresses.

Jonas

JoshyFun
to Graeme Geldenhuys: Sorry, but I know the output below is going to wrap horribly. I'm self-taught when it…

Hello Graeme,

Monday, November 3, 2008, 3:10:49 PM, you wrote:

GG> 1) Every "Call trace for block" is a memory leak, correct?

Yes, but take care, two strings in a non freed object (in example) will produce three memory blocks. 1 for the object and one for each string.

GG> 2) Each "Call trace for block" is where the memory was allocated GG> (start being used)?

Where it has been allocated or reallocated (it could be used somehow later, or never).

GG> 3) I should trace the information from the bottom line to the top line...

To follow the sequence yes.

GG> 4) Why does it quote more than one line? If I allocated memory on a GG> specific line, should just that line be quoted?

You may allocate a memory block in the same line following different paths, finally all memory blocks are a "GetMem" so if only one line is quoted you will only see "GetMem" procedure.

Best regards, JoshyFun
Graeme Geldenhuys
to Jonas Maebe: Yes. Allocated. It's a backtrace, like when an exception or run time error occurs. The…
Jonas Maebe wrote 5 lines
> 3) I should trace the information from the bottom line to the top line... It's a backtrace, like when an exception or run time error occurs. The top line is the actual place where the allocation happened, the next is the caller of that place, etc.

Perfect, that's what I wanted to confirm.

Show quoted text 5 lines
> 4) Why does it quote more than one line? If I allocated memory on a > specific line, should just that line be quoted? I don't understand what you mean with "quote more than one line". However, things like this:

JoshyFun's explanation helped here. It's the code path (sequence) leading up to the 'allocate memory' call.

Thanks both to Jonas and JoshyFun for helping out. Incidently, my application is now "leak-free". :-)

I also made a note to self:
"Enabled heaptrc unit for all projects while I develop! It's easier to trace the problem just after you caused it, than to try and hunt it down weeks later."

Thanks guys!

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

dmitry boyarintsev
to Graeme Geldenhuys

Graeme.

If you're using Lazarus, you'd probably be interested in using LeakView package.

If you write out HeapTrc output into separate file, then LeakView dialog will allow you to read the file, and present the the leaks in compact tree-view style. Also, it will allow you to quick jump by double-clicking. to the line, causing the leak .

You can write out HeapTrc into separate file in two ways:

1) if your project uses HeapTrc unit, then you can specify file name by
using procedure SetHeapTraceOutput(filename);

2) if you're using -gh compiler option, then you should specify environment variable, IIRC: HEAPTRC:log=filename

LeakView has been included in Lazarus Package list, so the only thing you need is to rebuild IDE with the package included.

Graeme Geldenhuys
to dmitry boyarintsev
dmitry boyarintsev wrote
If you're using Lazarus, you'd probably be interested in using LeakView package.

I started using it 10 minutes after it was committed to trunk. :-) LeakView is very handy indeed!

One small suggestion though. Can you include the summary information in that dialog as well? By summary information I mean the following... ------------------------
Heap dump by heaptrc unit
21345 memory blocks allocated : 921443/1006336
21345 memory blocks freed : 921443/1006336
0 unfreed memory blocks : 0
True heap size : 655360
True free heap : 655360
----------------------------

I'm mainly interested in the number of unfreed memory blocks.

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/