Moreover I extensively use generics of FLG (in particular TFPGObjectList) that sometimes cause internal errors during compilation (that disappear after i purge the lib folder with binary files).
Looks like exactly the problem I was struggling a month ago. NEVER free
TFPGObjectList elements BEFORE destroying the List iteslf.
E.g. the situation looks like.
You have a
TFPGObjectListYou create and operate
TFPGObjectList and finally you free (or the free is done automatically) some of its content.
You close the app.
It calls destructor which frees
TFPGObjectList and it tries to access already freed memory area.
In case you are in IDE you'll see a SIGSEGV, in case you're in the OS you'll only see a console message.
How can this happen.
1.
You have two
TFPGObjectListBoth have
OWNS OBJECT = true;They share some (one is enough) of their elements.
You free one of them. It frees all of its content.
You free another and it tries to access memory already freed. Therefore
SIGSEGV.
2.
You have a
TFPGObjectList with
Owns objects = trueYou add elements to it. However, you forget that the
TFPGObjectList owns the object and try to manage some of those manually (even in case of exceptions/errors), or automatically (e.g. by
TComponent ownership).
you get one of the
TFPGObjectList elements freed (maybe in other
destructor).
You close the app and
TFPGObjectList tries to access memory already freed. Therefore SIGSEGV.
How to tell if that is the problem? Try setting
OwnsObjects (I don't remember exact variable name) to false, which is most generally done by
TFPGObjectList.create(false) instead of
TFPGObjectList.create or
TFPGObjectList.create(true);If the error goes away into memory leaks then this is the case
Then just carefully scan your code against manually/automatic freeing elements of
TFPGObjectList
Recent
