[fpc-devel] Why/how does the compiler have a non-trivial number of memory leaks after over two decades of development?

[Ben Grasset]

I'm somewhat surprised to see all the mentions of try-finally in 
response to this.

The issues I found and described here are all clearly just simple cases 
of variables being created and then never freed. Part of what likely 
leads to this is that the compiler relies in many places on checking 
whether or not things are currently nil, and heavily reuses global 
variables for this purpose.

So it's quite likely in my opinion that there's places where things are 
in fact being set to nil without actually being freed first, which has 
the potential to go beyond basic leaks and actually lead to memory 
corruption problems than could cause real compiler bugs (and might 
already be doing so.)

I really don't think that try/finally is particularly relevant for this 
kind of thing, nor would it be good for compiler performance. I do think 
however that it's quite viable to get some kind of system in place in 
the compiler codebase (hidden behind one of the debug-related ifdefs so 
that it never affects normal compiler builds at all) that would allow 
for much easier soundness-checking while working on the compiler than 
HeapTrace can provide on its own.

I've been trying out a few different approaches in the last few days, 
and if there's any interest in something like this from the compiler 
team I might post here for feedback once I get something more concrete 
worked out.