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

[Michael Van Canneyt]

On Mon, 30 Jul 2018, J. Gareth Moreton wrote:

>
>
> On Mon 30/07/18 01:58 , Ben Grasset 
> operator97 at gmail.com sent:
>> I was even able to successfully actually 
> fix some of the leaks, but others
>> boiled down to a "node" being created as 
> a local variable in the middle of
>> some 1000+ line method, getting assigned 
> to the "left" or "right" property
>> of some other globally visible node, and 
> then never being freed.
>> To add to that, some of then actually 
> *could not* be freed even when I
>> tried to do so without raising an 
> untraceable access violation later in the
>> compilation process, also, which means 
> the compiler is basically knowingly
>> relying on undebuggable undefined 
> behaviour in multiple places that could
>> easily be affected or altered by 
> anything else anywhere else in the
>> codebase at any time. 
>> The way-too-short, highly undescriptive 
> naming of variables doesn't
>> exactly help, either! "hp" and "p" are 
> not good variable names. They really
>> aren't! 
>> 
>> Overall, I'm not trying to put blame on 
> anyone in particular here, but as
>> someone who loves using FPC and would 
> like to see it continue to grow, it
>> would be nice if we could collectively 
> address some of these basic,
>> fundamental issues (which I'd be happy 
> to help with myself, of course.) 
>>
>
> I too love Free Pascal and seek to improve 
> it. If you've found a fix, by all means 
> submit it as a patch in the bug tracker.
>
> I've noticed that the compiler doesn't use 
> try...finally blocks to help with freeing 
> blocks. I'm not sure why this is the case, 
> but might be speed related.

Yes. try/finally blocks cause *tremendous* slowdown.

Michael.