J. Gareth Moreton
2018-07-30 10:30:57 UTC
> 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
> 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.
More complex refactoring might require
deeper planning and approval from Florian.
For example, the node construction relies
a lot on global variables (especially
current_procinfo) that could possibly use
I think a big issue with refactoring is
the amount of testing required because of
the numerous target platforms.
Don't be disheartened though. With enough
eyes, all bugs are shallow!
Gareth aka. Kit
fpc-devel maillist - firstname.lastname@example.org