where can I locating the error

[taazz]

I checked: fScreenLevels was actually nil. But fScreenLevels.free produced no SIGSEGV. Swiching to .ToString boom, it came.

Free on a nil object will never give a SIGSEGV. (It's made that way)

This will work fine:

Code: [Select]

var
  a: TObject;
begin
  a := nil;
  a.free;
  a.free;

This however does not work:

Code: [Select]

var
  a: TObject;
begin
  a := nil;
  a := TObject.Create;
  a.free; // <------- not nil after free
  a.free; // <------- this fails

That's why, if you want to reuse the fXXX objects you'll need to nil them. But if your design is made that they are not reused it's not necessary (and even unwanted) to nil them.
(unwanted because: https://www.delphitools.info/2010/02/06/dont-abuse-freeandnil-anymore/)

It is interesting that it does give a SIGSEGV in the debugger but no exception outside the ide.

Not that old bug of farts again. Freeandnil defensive programmins and allthat is abuse because he has an easier time to debug with out them? yeah right. the number one responsibility of the programmer is to make sure the program does it job the number two is to make sure it will never crash and burn. It is not to make the lifes of those following easier or to make things easy to comprehend.

[rvk]

the number one responsibility of the programmer is to make sure the program does it job the number two is to make sure it will never crash and burn.

And if you do a good job on number one you'll never have to worry about number two

But like I said... when I know the object is never used again (i.e. right before exiting your program) I don't bother assigning nil to it (but maybe others do it differently). But if you're not sure, then you should nil them.

[kapibara]

Just a shot in the dark: Do you use threads somewhere in the program? I have got unexplainable SIGSEGVs on closing the app or form when I "forgot" to update the GUI in a syncronized way.

[taazz]

the number one responsibility of the programmer is to make sure the program does it job the number two is to make sure it will never crash and burn.

And if you do a good job on number one you'll never have to worry about number two

70% there. This was true on the synchronous world of DOS and CPM. On the Async world of windows and preemptive multitasking this is partialy true. In the modern world the safe thing to do is first nil then free the object and make sure that the nilling part is made thread safe if possible too (interlockexchange).

But like I said... when I know the object is never used again (i.e. right before exiting your program) I don't bother assigning nil to it (but maybe others do it differently). But if you're not sure, then you should nil them.

well an internal object on a class is not supposed to be used when the class is in the destructor but I had a couple of crashes because of interconnected objects and now I'm testing for the destructor flag too that makes it even harder to follow the "true" flow of the program. Oh wait isn't async suppose to not rely on specific flow only ... oh ok ok I'm of the forums for tonight hijacked an other thread again sorry.

[rvk]

Maybe a wild idea, but since you say you only have the SIGSEGV in the IDE, and you don't get an exception outside the IDE, you could try the newer version of the GDB debugger.

You can find the newer "Alternative" version of GDB here:
Lazarus Windows 32 bits / Alternative GDB


I've had problems with the standard one when using TOpen/TSaveDialog in Windows (when exiting my program in the IDE) so I switched to this newer one.