heaptrc output truncated at 1kb ??

[PJS]

Hi,

Please be gentle with my misunderstandings - while I've had many, many years experience with Delphi, I'm a complete noobie with Lazarus

(In my retirement, I'm investigating mORMot for some home projects but that is too much of a mouthful for my ancient personal copy of D2006.
Although I'm really impressed with Lazarus/FPC, the subtle differences do trip me up)

Ok...

A recent major change to one of my first "real" (20+unit) programs shows 4 unfreed blocks in the 1KB .TRC file but no Call Stack - and I can't find any way to get more information on the leaks

>>>
D:\Lazarus\PJS\WalkClubs\WalkClubEditor\WalkClubEditor.exe
Heap dump by heaptrc unit of D:\Lazarus\PJS\WalkClubs\WalkClubEditor\WalkClubEditor.exe
10181 memory blocks allocated : 2680939/2702112
10177 memory blocks freed     : 2680459/2701632
4 unfree
<<<

A small test program with a deliberate memory leak does correctly generate a larger (3KB) .TRC file with Call Stack, addresses, procedure names, line numbers, etc, etc showing *all* of the unpaired memory allocations.

It was only later, after I'd moved the program to a different folder, that I realised that my .TRC file was being truncated - and at /exactly/ 1,024 bytes

I couldn't find any forum post mentioning any similar truncation.

I did find (older) posts suggesting /not/ having "using heaptrc" in my own source - but if I don't, how can I access "SetHeapTraceOutput" or "GlobalSkipIfNoLeaks"?   


What stupid mistake have I made to have this effect on the .TRC file?

Thanks in advance for any help
Paul


Lazarus v3.2
FPC     3.2.2
Windows 10 Pro x86_64 22H2

Project Options...
D:\Lazarus\Lazarus3.2\fpc\3.2.2\bin\x86_64-win64\fpc.exe
-MObjFPC
-Scaghi
-CirotR
-gw3
-gl
-gh
-Xg
-gt
-WG
-l
-vewnhibq
-Filib\x86_64-win64
-Fi..\..\..\mORMot2\src
-Fi..\..\..\mORMot2\src\core
  ...
-Fu..\..\..\Lazarus3.2\packager\units\x86_64-win64
-Fu.
-FUlib\x86_64-win64
-FE.
-oWalkClubEditor.exe
-dLCL
-dLCLwin32

[dbannon]

.....
I did find (older) posts suggesting /not/ having "using heaptrc" in my own source -

In the early days, it was necessary to mention the heaptrc unit in the "uses" section of your code. That is no longer the case, all you need now (and all you should do) is tick the box in the Lazarus IDE Debugging page or ensure "-gh" is on the compile line (as it is already from your text).

but if I don't, how can I access "SetHeapTraceOutput" or "GlobalSkipIfNoLeaks"?   

I have no idea.
I do my dev work on linux and, on a really bad day, can see a lot of heaptrace output. But its done differently on Linux, just a feed to stdout, on Windows, its captured somehow and displayed in a dialog. So, maybe, just maybe, there is a limit to how much can be displayed in that dialog ? No idea.

I find the best approach is to regularly test for leaks, especially in the early days. That way, you usually will only see one leak at a time.

Sorry I cannot be of more help. At least my post will bring your question back to the top of the list .....

Davo

[TRon]

but if I don't, how can I access "SetHeapTraceOutput" or "GlobalSkipIfNoLeaks"?   

I have no idea.

By f.e. using:

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

1. {$if declared(UseHeapTrace)}
2. GlobalSkipIfNoLeaks := true;
3. {$endif}
4.  

Whenever the heaptrace unit is included (-gh) that declaration is present/active and so will compile in those lines. Otherwise these lines will be ignored.

Ofc you could use any heaptrace specific declaration but this one seem to be one of the more suitable ones, see also https://lazarus-ccr.sourceforge.io/docs/rtl/heaptrc/useheaptrace.html

[PJS]

Overnight I realised something else I should have added in my original post

(I was distracted by several posts mentioning the "annoying series of modal popups" generated by the leak report in Windows and I didn't actually take enough care to read what was actually shown in the popups before dismissing them in my rush to get to the .TRC file)

The error message does suggest that I'm getting an AV within heaptrc itself

I have attached screenshots in case the addresses might mean something to someone more experienced

(To the extent that I had thought about it, I did think this was a strange way of the system announcing a memory leak)

I did try to set a breakpoint within heaptrc but, of course, that doesn't work in low-level modules which have been built optimised and, even if I did spend hours working out how to rebuild heaptrc with debugging enabled, that isn't going to tell me what's gone wrong and whereabouts in my code

(Although there are 4 leaks, they are probably all caused by one of the many call-backs I've got from general-purpose "abstract" routines)

So, I suppose I'll have to resort to commenting out blocks of code to identify the code which does - and does not - cause the leak

Anyway, if you have been, thanks for listening
Paul