3

In Delphi XE I always used ReportMemoryLeaksOnShutDown to detect any leaks when exiting my Applications, most my projects were rather small and finding the leaks was usually not too difficult.

In Lazarus there is no such option but I have just found out an option called Heaptrcon, more information on this page: http://wiki.lazarus.freepascal.org/Profiling

In Project Options > Linking I have set the (-gh) flag, now my fears of any leaks have become a reality. I would post code but because there are a lot of different classes and units I have no idea where to begin in fixing these leaks, this is a project far larger than any other I have worked on.

This a screenshot of some of the leaks:

enter image description here

My debugging skills are practically zero, so far I have looked to see every Object or Class I have created, and then checked to see if it has been freed. Because I am working with a lot of TLists and Pointers/Objects etc the leak could be coming from anywhere I guess.

Is there any clues or tips of where to even begin looking? I am looking at the call stack for each block that is size 16, and there is 6 of them, could this mean there are 6 objects not been destroyed correctly?

I am at a loss, where to begin?

Thanks in advance.

  • 1
    You really need to convert those addresses into function names. Surely there's a way to do that with FPC. – David Heffernan Sep 04 '13 at 13:10
  • @DavidHeffernan I had no idea, I need to see if that is possible it would help massively. EDIT: I had debugging info turned off, now I have function names. I really want to try and solve this one myself so if I could put the question on hold for now maybe..? –  Sep 04 '13 at 13:12
  • 1
    "Lineinfo" (-gl) is the FPC parameter to look out for. – Marco van de Voort Sep 04 '13 at 18:00
  • @MarcovandeVoort I have found leaks all over the place, have been on all day trying to debug them. I seem to fix loads then new ones start appearing :( –  Sep 04 '13 at 20:59
  • The only issue I know with memprofiling (other than Delphi) is that memory leaks in the main program are not always detected correctly. (Afaik there is something wrong or variable in the order of finalization of units, including the memory unit one one hand and finalization of global vars local to the main program) – Marco van de Voort Sep 05 '13 at 07:20

2 Answers2

3

The information you really need is the stack traces for the allocations associated with each leaked object. They are present in your screenshot, but presented as addresses rather than function names. Enable debug info and the names will be presented to you. You can then trace the problems in just the same way as you would with FastMM in Delphi.

David Heffernan
  • 601,492
  • 42
  • 1,072
  • 1,490
2

As David Heffernan mentioned in one of his earlier comments there should be a way to convert those addresses into function names.

The first step was to make sure I had enabled Generate debugging info for GDB which for some reason was not enabled, then I got those function names.

After tracing the addresses they led me to my TList Objects. Now this project I am working on was actually started in Delphi XE but I on porting to Lazarus, and these errors were not picked upon in XE, but when freeing my TList Objects I did this:

var
  P: Pointer;
begin
  for P in MyList do TMyListItem(P).Free;
end;

I don't have XE installed to test but I remember getting no errors with the above.

I was also adding Objects to a Treeview (those Objects been pointers from MyList) and I was not freeing these. But even after doing that my leaks were still present.

After hours of trying different things and close to giving up, I realised I missed out something simple:

var
  P: Pointer;
begin
  for P in MyList do TMyListItem(P).Free;
  MyList.Free;
end;

I missed that part out in Delphi and I am positive it didn't complain about any leaks, but in Lazarus/FPC I got a ton of new leaks. So far all my leaks have gone (hopefully) and no more will come back.

Now I get this leak report which looks less scary because it is reporting zero leaks:

enter image description here