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

[J. Gareth Moreton]

 Being your hero is a good enough reason for me!  One little thing that's
driven me, even though it's not really an issue, is the size of the EXE
files that are produced, so I seek to find any little way to shrink them
down without compromising performance in the final binary.

 What I like about this project is that we all have our little motivators
and objectives, and we're free to explore and research.  I had an idea to
potentially improve the compiler speed on modern systems, but requires a
lot of refactoring and I'm currently got my attention focused on
researching pure function support.
 One drawback with any kind of memory management code is that it can put a
lot of space and speed overhead on your project, although it is very useful
from a debugging point of view.  I've programmed my own ones in the past
for C-based test projects that are meant to run for 24 hours sometimes,
mostly in response to frequent crashes.  It's proven very useful in
catching memory leaks and identifying where they are so the memory can be
freed properly.
 So, long story short... if you find memory that isn't freed, free it (once
you check it's not used afterwards), even if the operating system or RTL
cleans it up for you.

 Gareth aka. Kit

 On Mon 30/07/18 15:05 , "Karoly Balogh (Charlie/SGR)"
charlie at scenergy.dfmk.hu sent:
 Hi, 

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

 > I would say that that's a little naïve and dangerous to think like
that. 
 > Sure, Windows might have the means to clean up memory after an 
 > application terminates, but not all platforms have such heap 
 > deallocation features (e.g. pure DOS, where certain procedures and 
 > interrupts remain in memory even after the application terminates... 
 > so-called memory-resident programs). 

 While I generally agree, in practice it's usually a non-issue. 

 Pure DOS, as in the 16bit target is not supported to run the compiler, 
 only via GO32V2, and having DPMI TSRs is... well... :) 

 On Amiga and similar systems, AROS, MorphOS for example, which indeed does

 not free up the memory after a program terminates, I implemented a memory 
 pool in the FPC RTL, so all memory is freed anyway during the program's 
 exit. Any application which wants to go beyond this behavior for whatever 
 of its own reasons is free to use the OS allocation functions directly, or

 implement its own memory manager. The same with open files on this 
 platform, actually, which wouldn't be closed without the RTL taking care 
 of them. And I also have to manage our own stack, and lets not even 
 mention threading... :) 

 The sideeffect is, that this approach silently "fix" the compiler's own 
 leaks too, so FPC remains useable on these systems. In general it is much 
 safer anyway, because expecting all the broken code out there to get fixed

 for such systems is sadly just naive. 

 Having this said, anyone who still fixes leaks win the compiler will be my

 hero! :) 

 Charlie 

 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20180730/9974e212/attachment.html>