Memory leak in pareto

[charlesknightsbridge]

Reproduce in debug mode: read ....epx; pareto var; quit;

Lazarus reports a DrawDataLeak

This only happens with pareto command. It is the only graph command that uses axis transforms and 3 axes.

I tried using heap trace, but still can't get any useful information; I must be missing an option to get unit/line numbers attached to the call trace for each block.

The memory leaks are massive:

Total Mem allocated: 4233368737 Leaking Mem Size: 6415887 Leaking Blocks Count: 12575

Not sure where to go with this.

[charlesknightsbridge]

At the end of the output from heap trace are a few messages pointing to epi_osxlocale.pas, which doesn't make sense. That's a unit I borrowed from somewhere else and everything it creates or copies is destroyed within a few lines. The next leaks that could be matched with source code lines pointed to something in LCL. So either I'm using heap trace wrong or it's not working very well.

Then there are some that do make sense, in graphform.impl, output, where objects get created, but there is no destructor block. In the grand scheme, some these may not be really important, if they get created once only, but graphform and output objects get created by many procedures.

Where to start? I added a destructor to graphform and it didn't cause any problem. But I have to do a debug run to see if it no longer leads to a leak.

Advice????

[torstenchr]

In general Analysis has a lot of memory leaks, unfortunately. They are scattered all over the place so using the heap trace unit at this point makes no sense.

I will try to dig into the code and see what I can find.

[torstenchr]

@charlesknightsbridge I believe i fixed the problem. It took a very very long time to track it down.

Apparently the axis transformation has a different pattern during destruction and by assigning them to "chart" in the contructor something messed it up. Unfortunately it also surfaced a bug in the overall chartfactory which also had to be fixed for all the things to work.

I still consider it a work-around, because we potentially still leak some memory, but it will not give any error for our users now.

[charlesknightsbridge]

Solved