[Solved] Memory leaks when using TChart

[Wilko500]

MacOs Sequoia 15.6.1

My Inverter logging app is progressing well but . . . under testing I have found a significant memory problem, unlike anything I have encountered yet, "Application paused Out of Application memory".  When application fails MacOs reports  application memory approx 140Gb! and that is roughly the amount of free disk space on my Mac.

Do I have memory leaks? Yes, 17 unfreed blocks.  Used debug mode and managed to get this down to 9 blocks.  The remainder are still present but the limited line info points toward stuff that is not in my code.  I began to compare the failing program with a prototype that does not have the unfreed blocks.  The main difference is Charts so that is where I started my investigation.

I created a new project containing a single TChart with a single LineSeries. Compile. Run from terminal and on exit 3 unfreed blocks, 2 for the chart, 1 for the LineSeries.  Adding a second chart does not increase the unfired blocks. First part of the dump is below.

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

1. Heap dump by heaptrc unit of /Volumes/MacHD-SSD-Data/LocBucket/FpLazStuff/ZTest/project1
2. 2473 memory blocks allocated : 1238099/1241992
3. 2470 memory blocks freed     : 1237971/1241864
4. 3 unfreed memory blocks : 128
5. True heap size : 983040 (96 used in System startup)
6. True free heap : 982176
7. Should be : 982240
8. Call trace for block $00000001EA773E00 size 48
9.   $000000010FE9DFE1
10.   $000000010FD2A496
11.   $000000010FD19B0A
12.   $000000010FD1A14A
13.   $000000010FD1AEC0
14.   $000000010FD1E9DA
15.   $000000010FD1EC89
16.   $000000010FF75409
17.   $000000010FF3F9A5
18.   $000000010FF8B2B2
19.   $000000010FF7FA94
20.   $000000010FF0AE9F
21.   $000000010FF0D334
22.   $000000010FF049E1
23.   $000000010FF0177E
24.   $000000010FF044AD

I don't recall seeing anything in the documentation about needing to free charts or series. Perhaps someone can verify my findings or explain what is happening?  I don't have access to Windoze to test but I do wonder if this is a Mac thing


 

[wp]

I have a VM with a Mac OS 10.14 Mojave and can confirm the issue there. I cannot confirm it, however, on Windows, Linux gtk2, gtk3, qt5, qt6. Therefore I am rather sure that the memory leak originates somewhere outside TAChart.

On the mac-VM is switched the chart to be invisible (Chart1.Visible := false) - no more memory leaks. This seems to indicate that the memory leak somehow has something to do with painting.

[Wilko500]

Thank you.  I confirm you setting Chart1.Visible:=false does prevent the memory leak.  That is very interesting because I have in the past seen a small test program with memory leaks with no user code involved but in that case not a chart but buttons, edits and maybe a checkbox.  I'll see if I still have that test program, it might have the same cause, maybe a bug??

I doubt if this is the cause of my Application Out Of Memory issue so more test required there.



 

[wp]

Played a bit in Laz/cocoa to find memory leaks. Here is a very simple one:

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

1. procedure TForm1.FormPaint(Sender: TObject);
2. begin
3.   Canvas.TextOut(0, 0, 'Test');
4. end;

Can you confirm this? If yes, I'll file a bug report.

[Wilko500]

Yes, I confirm your test. On program exit I get

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

1. 634 memory blocks allocated : 1101756/1102248
2. 632 memory blocks freed     : 1101676/1102168
3. 2 unfreed memory blocks : 80
4. True heap size : 1769472 (96 used in System startup)
5. True free heap : 1768864
6. Should be : 1768912
7. Output truncated by me

[wp]

Reported as https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/41824

[Wilko500]

Many thanks

[Wilko500]

I have been doing additional testing on my prototype program.  We have established that memory leak is probably related to font creation, so I attempted to make all objects on my form default font.  This failed to clear the last two unfreed blocks. I did this by editing the .lfm files to remove all references to the font Tahoma that I had been using. Undeterred I continued investigations.

What I eventually discovered is that the two remaining unfreed blocks were caused by making any one of the labels DCDC1/DCDC2/Inverter visible (see pic).  I have two grpBoxes, one inside the other, all fonts in both are Tahoma.  Elsewhere on the form I have grpBoxes with both edit and labels all with Tahoma that work fine. 

The unfreed blocks only seem to occur with nested grpBox.  It was this nesting that made it so difficult to identify.  In the final version of my program I used panels rather than grpBoxes and I wonder if the same problem would occur with nested panels.  I have not had time to test this yet.

[wp]

The Canvas.Font related memory leak in cocoa now has been fixed. Please test again.

[Wilko500]

Have tested with Fpcupdeluxe - Trunk.  I am not seeing the memory leaks  .  Have checked with the original test program and two other programs with far more complex GUI's.  None show memory leaks.  Next step will be test in live environment.  A necessary test because prior to the fix with all items causing leaks either deleted or made invisible, thus on compile and exit 0 leaks, still has continuous increase in "Private Memory Size" which eventually crashes the program.  I have no idea whether this is related to the canvas leak or something else.

Thank you, and the Team, for your help fixing this issue.

PS: With the latest Trunk I do see a significant difference in how the Chart left axis is being scaled.  I will create a new thread for this

[Wilko500]

Marking this as solved