heap message

[xaver13]

Hello, I have application, which I can run on windows under lazarus.
On the end I have message:
Heap dump by heaptrc unit.
..
True heap size 360448
True free heap 360320
Should be 360448
..
When I run the exe the message is the same.
The same application has no problem on Linux.

What should be wrong? Thank you.

[Thaddy]

Can you please compile with -glh or in Lazarus check line numbers option? Otherwise heaptrc is rather useless....
And the problem is likely the same on all platforms....

[xaver13]

I uncheck " Heaptrc unit" in other debugging info, for project options and I am happy   

--
Thank you for help, Thaddy.

[Bart]

That also works for:

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

1. var
2.   p: pointer;
3. begin
4.   GetMeM(p,1024*1024*1024);
5. end.

See: no error message at all!
Just ignore you have a 1 GB memory leak 

Bart

[winni]

Bart's answer is good.

But with this you have more fun:

 

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

1.   var
2.       p: pointer;
3.       i : integer;
4.     begin
5.       for i := 1 to 16 do
6.       begin
7.       GetMeM(p,1024*1024*1024*i);
8.       showMessage ('Still alive?');
9.       end;
10.     end.

[ASerge]

Heap dump by heaptrc unit.
..
True heap size 360448
True free heap 360320
Should be 360448
..

Show the full message, please.

[Martin_fr]

He may just refer to the fact that heaptrc *always* prints some statement, even if there is no leak.

On Linux this would not have bothered him much, since it goes to console (or debug output window, which may be closed).

But on Window, for GUI app, it causes a pop up every single time your app finishes.
While that is fine, if you actually check for leaks, if/when you look for other issues that can be distracting.

I recommend in that case to compile with -WC which will give you GUI app an additional console.
It will close before you can get the report, but you may be able to see, if anything was printed (especially if there a lots of leaks).
And using fpdebug (svn trunk) and an IDE build with console too, the leaks can be printed to the IDE's console which will stay open, so they can be copied.

[PascalDragon]

I uncheck " Heaptrc unit" in other debugging info, for project options and I am happy   

You shouldn't ignore a memory leak. Especially if it is something that leaks regularly your application might require more and more memory if it's running a long time.

[xaver13]

Heap dump by heaptrc unit.
..
True heap size 360448
True free heap 360320
Should be 360448
..

Show the full message, please.

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

1. jiricvrk@jc-TP25:~/Pascal/Sportka$ ./sportka
2. Gtk-Message: 10:46:51.680: Failed to load module "canberra-gtk-module"
3. Heap dump by heaptrc unit
4. 23134 memory blocks allocated : 2092458/2151208
5. 23134 memory blocks freed     : 2092458/2151208
6. 0 unfreed memory blocks : 0
7. True heap size : 819200
8. True free heap : 819200
9. jiricvrk@jc-TP25:~/Pascal/Sportka$
10.  

this is full message from ubuntu, thank for reminding to look at the console.


and in windows:

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

1. Error
2. Heap dump by heaptrc unit
3. 27752 memory blocks allocated:2471849/2554856
4. 27752 memory block feed:2471849/2554856
5. O unfreed memory blocks: 0
6. True heap size: 425984
7. True free heap:425856
8. Should be: 425984
9.  

[Thaddy]

Which is correct... it tells you there are no leaks.

[Martin_fr]

As far as I know:

Heaptrc is initialized as early as possible. But there may be other stuff happening just before this (or maybe/guessing the OS adds some offset that is not reported correctly). Then whatever happens before can not be correctly reported.

Memory allocation is separated into 2 parts:
A- get huge chunks from the OS (getting small chunks can be very expensive or even impossible)
B- when your code allocs mem (strings, classes, getmem(), ...) then small parts of the big chunk are returned

If  in "B" your app code (or the RTL) gets mem, and does not return this (return to the big chunk), then that is reported as leak.

My guess is that the "Should be" stuff is somehow related to the "big chunk" allocation. (and can not be influenced in your code)

[Thaddy]

heaptrc is initialized at compiler level, not unit level. It should be always first therefore. This is documented.

[PascalDragon]

heaptrc is initialized at compiler level, not unit level. It should be always first therefore. This is documented.

The compiler injects heaptrc as early as possible in the unit initialization table, but the System unit is always first. Thus any initialization the System unit does is done on the non-heaptrc heap.

[Thaddy]

heaptrc is initialized at compiler level, not unit level. It should be always first therefore. This is documented.

The compiler injects heaptrc as early as possible in the unit initialization table, but the System unit is always first. Thus any initialization the System unit does is done on the non-heaptrc heap.

AFAIK Florian explained that heaptrc is included at the point that the compiler needs to allocate dynamic heap memory. This documented  behavior differs from lower than 3.0.2 (which was the same but not documented), I believe.
If you are correct I will have to adapt the wiki.

[PascalDragon]

Just look at the INITFINAL table that the compiler generates for the final executable (use -al and search in the resulting .s file of the main program). You'll see this:

Code: ASM  [Select][+][-]

1. .section .data.n_INITFINAL,"d"
2.         .balign 4
3. .globl  INITFINAL
4. INITFINAL:
5.         .long   3,0
6.         .long   INIT$_$SYSTEM
7.         .long   0
8.         .long   INIT$_$HEAPTRC
9.         .long   FINALIZE$_$HEAPTRC
10.         .long   INIT$_$FPINTRES
11.         .long   0

The RTL walks this table from top to bottom.

Additionally if the System unit would be initialized after the heaptrc unit then the System unit would overwrite the memory manager of the heaptrc unit.