Tracking down memory leaks

[backprop]

Is there a way here to tracking down memory leaks?

In Delphi I used some other memory manager to do that, but how that can be accomplish in FPC/Lazarus?

[Martin_fr]

"Heaptrc"
Project Options > Debugging > checkbex "Use HeapTrc -gh"


Or if you are on Linux, "valgrind" (that is a separate app).

[Thaddy]

Read the wiki for correct use of heaptrc, And it also works on Linux,
And the option should be -glh not -gh

[backprop]

Thanks. Basic options seems to be -gl and -gh.

I would need to see what that  "valgrind" app actually can do, if basic options are not enough...

[Thaddy]

valgrind is overkill for tracing memory leaks. heaptrc is just as good if not better.
So -gl -gh or in short -glh

[Martin_fr]

valgrind is overkill for tracing memory leaks. heaptrc is just as good if not better.
So -gl -gh or in short -glh

If you think though....

I don't fancy recompiling FPC (or the RTL) just because I need a longer stacktrace. Using valgrind I can specify it on the command line.
And yes, in many cases the amount of frames shown by heaptrc are enough. But not quite always.

And possible that FPC can cut off traces.

Using FPC 3.2.2 (as it comes, so NO debug info for RTL and RTL compiled with -O2 ), below project compiled WITH no optimization and -gl and then either -gh or -gv

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

1. program Project1;
2. uses SysUtils, Classes;
3. var
4.   s: TStringList;
5.  
6. function DoSort(List: TStringList; Index1, Index2: Integer): Integer;
7. begin
8.   allocmem(20);
9. end;
10.  
11. begin
12.   s := TStringList.Create;
13.   s.Add('1');
14.   s.Add('2');
15.   s.Add('3');
16.   s.CustomSort(@DoSort);
17.   s.Free;
18. end.
19.  

Heaptrc gets me

Code: Text  [Select][+][-]

1. Heap dump by heaptrc unit of /tmp/project1
2. 28 memory blocks allocated : 1939/1968
3. 25 memory blocks freed     : 1879/1896
4. 3 unfreed memory blocks : 60
5. True heap size : 393216
6. True free heap : 392448
7. Should be : 392568
8. Call trace for block $00007F506696B200 size 20
9.   $0000000000468F81
10. Call trace for block $00007F506696B100 size 20
11.   $0000000000469009
12. Call trace for block $00007F506696B000 size 20
13.   $0000000000469009
14.  

And valgrind

Code: Text  [Select][+][-]

1. ==2274==
2. ==2274== HEAP SUMMARY:
3. ==2274==     in use at exit: 84 bytes in 3 blocks
4. ==2274==   total heap usage: 28 allocs, 25 frees, 2,163 bytes allocated
5. ==2274==
6. ==2274== 28 bytes in 1 blocks are definitely lost in loss record 1 of 2
7. ==2274==    at 0x483DD99: calloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
8. ==2274==    by 0x4269F1: CMEM_$$_CALLOCMEM$QWORD$$POINTER (in /tmp/project1)
9. ==2274==    by 0x466630: CLASSES$_$TSTRINGLIST_$__$$_QUICKSORT$LONGINT$LONGINT$TSTRINGLISTSORTCOMPARE (in /tmp/project1)
10. ==2274==    by 0x4230FB: SYSTEM_$$_SYSENTRY$TENTRYINFORMATION (in /tmp/project1)
11. ==2274==    by 0x40120F: ??? (in /tmp/project1)
12. ==2274==    by 0x401189: SI_C_$$_MAIN_STUB (in /tmp/project1)
13. ==2274==    by 0x4881082: (below main) (libc-start.c:308)
14. ==2274==
15. ==2274== 56 bytes in 2 blocks are definitely lost in loss record 2 of 2
16. ==2274==    at 0x483DD99: calloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
17. ==2274==    by 0x4269F1: CMEM_$$_CALLOCMEM$QWORD$$POINTER (in /tmp/project1)
18. ==2274==    by 0x4666B8: CLASSES$_$TSTRINGLIST_$__$$_QUICKSORT$LONGINT$LONGINT$TSTRINGLISTSORTCOMPARE (in /tmp/project1)
19. ==2274==    by 0x4230FB: SYSTEM_$$_SYSENTRY$TENTRYINFORMATION (in /tmp/project1)
20. ==2274==    by 0x40120F: ??? (in /tmp/project1)
21. ==2274==    by 0x401189: SI_C_$$_MAIN_STUB (in /tmp/project1)
22. ==2274==    by 0x4881082: (below main) (libc-start.c:308)
23. ==2274==
24. ==2274== LEAK SUMMARY:
25. ==2274==    definitely lost: 84 bytes in 3 blocks
26. ==2274==    indirectly lost: 0 bytes in 0 blocks
27. ==2274==      possibly lost: 0 bytes in 0 blocks
28. ==2274==    still reachable: 0 bytes in 0 blocks
29. ==2274==         suppressed: 0 bytes in 0 blocks
30. ==2274==
31. ==2274== For lists of detected and suppressed errors, rerun with: -s
32. ==2274== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0)

Mind, both of them skip "DoSort" due to optimizations in the RTL by FPC.

Change it to

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

1. procedure Bar();
2. begin
3.   allocmem(20);
4. end;
5.  
6. function DoSort(List: TStringList; Index1, Index2: Integer): Integer;
7. begin
8.   bar;
9. end;
10.  

And "Bar" will be skipped, but DoSort will be shown.
HeapTrc:

Code: Text  [Select][+][-]

1. Call trace for block $00007F44A2EA4300 size 20
2.   $00000000004010C8  DoSort,  line 14 of project1.lpr
3.   $0000000000468F91
4.  

and valgrind

Code: Text  [Select][+][-]

1. ==2332== 28 bytes in 1 blocks are definitely lost in loss record 1 of 2
2. ==2332==    at 0x483DD99: calloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
3. ==2332==    by 0x4269D1: CMEM_$$_CALLOCMEM$QWORD$$POINTER (in /tmp/project1)
4. ==2332==    by 0x401257: P$PROJECT1_$$_DOSORT$TSTRINGLIST$LONGINT$LONGINT$$LONGINT (project1.lpr:13)
5. ==2332==    by 0x466610: CLASSES$_$TSTRINGLIST_$__$$_QUICKSORT$LONGINT$LONGINT$TSTRINGLISTSORTCOMPARE (in /tmp/project1)
6. ==2332==    by 0x4230DB: SYSTEM_$$_SYSENTRY$TENTRYINFORMATION (in /tmp/project1)
7. ==2332==    by 0x40120F: ??? (in /tmp/project1)
8. ==2332==    by 0x401189: SI_C_$$_MAIN_STUB (in /tmp/project1)
9. ==2332==    by 0x4881082: (below main) (libc-start.c:308)
10.  

I am not sure why valgrind didn't use the demangled name.... (test was done on an older Linux, with older valgrind 3.15

[Thaddy]

Yes I know that, but OP does not know that. That's the point and I am still laughing...

See: https://forum.lazarus.freepascal.org/index.php/topic,66265.msg506892/topicseen.html#new

Although you and I use valgrind, that does not mean beginners can use it. They should start by understanding the code first, in this case why it can't leak -example43 -, then use heaptrc and eventually learn about valgrind.

[Martin_fr]

Yes I know that, but OP does not know that. That's the point and I am still laughing...

Now you got me majorly confused.

So because the OP (probably) does not know that valgrind can is some cases be the better choice, you did tell the OP

valgrind is overkill for tracing memory leaks. heaptrc is just as good if not better.

Why? So he would never check it, even if hit a wall using HeapTrc? Or what?

Sorry, I don't get it.

that does not mean beginners can use it. They should start by understanding the code first, in this case why it can't leak -example43 -, then use heaptrc and eventually learn about valgrind.

I don't see, why "beginners" can't use it?

Just run it from the console, the syntax is easy to google, or can be asked for on the forum.

[Thaddy]

I editted my post. Plz have a look. Your post crossed my edit.

[Martin_fr]

As for the added cross ref post: I don't have your output. Not bothered enough to run that example myself now.

I guess it is one of the cases were potential leaks are reported. So basically an over-reporting.

IIRC they are somewhere marked as such. But its been a while I looked at that.