Using Heaptrace with Linux

[Curt Carpenter]

I'm using Lazarus 3.2 on linux.  In https://wiki.freepascal.org/heaptrc I find the following:

Using Heaptrc in Lazarus

To enable this in your Lazarus project:

    Go to Project Options/Linking and
    in the Debugging section enable Use Heaptrc unit (check for mem-leaks) (-gh)

You can test for the presence of Heaptrc in a similar manner as in the above example by testing for the presence of UseHeapTrace in your Project.lpr file.

Can anyone tell me where to look for Project Options/Linking ?  I've been looking on and off all day and just can't find it:  probably there and I'm just not seeing it.

Thanks.

[TRon]

menu->project->project-options
in left tree at compiler options select debugging
at right page under section "other debugging info" check "Use Heaptrc unit (check for memleaks) (-gh)"

While you're at it also check the option "display line numbers in runtime-error backtraces (-gl)"

[dbannon]

Curt, thanks for flagging that out of date wiki page, I have given it a bit of a tweak.

Davo

[TRon]

Thank you for the tweak dbannon 👍

[Zvoni]

Also be careful if you use another memory-manager (e.g. cmem)
See last paragraph "Why Heaptrc should not be added to the uses clause manually" on the Wiki

[MarkMLl]

Also be careful if you use another memory-manager (e.g. cmem)
See last paragraph "Why Heaptrc should not be added to the uses clause manually" on the Wiki

In my experience with dynamic linkage on Linux which mandates cmem, if you need HeapTrace for debugging then if /does/ have to be added manually but carefully positioned second (i.e. after cmem which is first).

MarkMLl

[cdbc]

Hi
Mark, I put it third, after 'cthreads', are there any problems in that?
Regards Benny

[MarkMLl]

Hi
Mark, I put it third, after 'cthreads', are there any problems in that?
Regards Benny

Let me take a look at a fairly big project. One moment please...

Code: Pascal  [Select][+][-]

1. (* Note manual addition of cmem below, this is required to allow strings and    *)
2. (* objects to be shared/transferred between the main program and a shared       *)
3. (* library. Note also relative position of HeapTrc, if cmem is used it is not   *)
4. (* possible to specify this at the project level (i.e. to use FPC's -gh option).*)
5.  
6. uses
7. {$ifdef USE_CMEM }
8.   cmem, {$ifdef USE_HEAPTRC } HeapTrc, {$endif USE_HEAPTRC }
9. {$endif USE_CMEM }
10.   {$IFDEF UNIX}
11.   cwstring,
12.   {$IFDEF USE_CTHREADS}
13.   cthreads,
14.   {$ENDIF}{$ENDIF}
15.   Classes, SysUtils, ...
16.  

I wouldn't have thought it would be significant, since threads are much more a runtime thing. I do recall the presence of cthreads in some other project being important in some non-obvious way... I really can't remember the detail though and even though I've almost certainly written it up in comments etc. I really don't know where to start looking.

All I can say is that what I've got there works for me, and is probably a useful fallback for anybody in case of non-obvious problems.

MarkMLl

[cdbc]

Hi
@Mark: Thanks mate, for checking...
I too will leave it as it is, since I'm not experiencing trouble, because I /always/ use threads and only once in a while 'heaptrace'.
If and when that fails, I can always come back and copy your approach 
Regards Benny

[dbannon]

Mine typically looks like this -

Code: Pascal  [Select][+][-]

1.     {$DEFINE UseCThreads}
2.     {$IFDEF UNIX}{$IFDEF UseCThreads}
3.    { cmem,} cthreads,
4.     {$ENDIF}{$ENDIF}  .....  

 

cmem at the start !  When I decide its time to do some heaptrc checking, I manually comment out cmem (as shown), obviously I loose much of the the benefit of threading but its only during debugging so who cares. So far, never had a release go out with cmem disabled !

Davo

[cdbc]

Hi Davo
I read it, like you're /always/ using 'cmem' instead of fpc-mem-man?!?
I'm aware of certain situations, where regarding threads the cmem is faster, but always?!?
...and ofc with libraries cmem is a certainty. { though I have fpcmemman too}
Regards Benny

[MarkMLl]

In the case of the project I quoted: it's very heavily oriented towards multiple threads for various subsystems, and I'm always using cmem because it can dynamically link a library to dump a (large) file for logic analysis or (potentially) to attach a non-standard peripheral. I'm fairly confident in its memory and thread management because multiple threads can output state info through the library simultaneously.

I was going to muse on whether, since the order is significant, both cmem and heaptrace insertion should ideally be done by the compiler. However since I'm talking about on-demand .so library loading rather than at-startup, this is probably outside what the compiler/linker could be expected to handle even if hinted by a commandline option.

What we obviously /don't/ want however is for either the compiler or the Lazarus IDE to try to rearrange things: I've already had situations where "LineInfo" was automagically rewritten to "lnfodwrf" which didn't help when I was trying to write my code to detect and report what format of debugging was being used.

MarkMLl

[cdbc]

Hi
Pheeewww,

I've already had situations where "LineInfo" was automagically rewritten to "lnfodwrf"

the above, I've yet to experience... 
Regards Benny

[MarkMLl]

I do recall the presence of cthreads in some other project being important in some non-obvious way... I really can't remember the detail though and even though I've almost certainly written it up in comments etc. I really don't know where to start looking.

Apologies for generating noise, but I've just found a note on this and thought it worth passing on.

Basically, I can't remember the symptoms or quite how I got to the fix, but the .lpr of a dynamically-linkable library called by multiple threads (protected by syncobjs in the caller) /had/ to import cthreads to work properly.

MarkMLl

[dbannon]

Hi Davo
I read it, like you're /always/ using 'cmem' instead of fpc-mem-man?!?
I'm aware of certain situations, where regarding threads the cmem is faster, but always?!?
...and ofc with libraries cmem is a certainty. { though I have fpcmemman too}
Regards Benny

Yeah Benny, sorry for late answer, some family issues at the moment.

cmem (and cthreads ?) is only a thing on Unix, probably does not even compile on Windows ? It makes a big difference with multithreaded code (I benchmark stuff like that). Not significant in an all single thread code (but not tested by me).

Davo