Re: SIGSEGV running the GC - solved

[mnicolet <mnicolet@...>]

Hello
Some days ago I posted a message telling a long story regarding a SIGSEGV
running one script
but no such running another, being both very alike.
The suspected spot was a premature collection of a user data object, not by
a GC misbehaviour,
but because a bad programming practice of my own, which leads my program
referencing
a freed pointer.
The question was: why one of the scripts and not the other ? the host
program is unique.
After that posting, I debugged the program running the ´crasher´ script.
The result was worser: the crash was happening in the luaL_loadfile function
when reading the first character of the file.
My ´fopen´ library defers the buffer allocation until some read operation is
requested, and there
was failing.
Cannot tell exactly how, because I can see only the assembler, and don´t
know which parameters are passed to that low level allocator module.
But the crash was well apart the supposed spot: I expected to find it near
some api function better
related to the userdata itself or in the GC code.
Truely, the crash was originated by a premature collection, because I leaved
the userdata ´orphaned´
( also having popped it from the stack ) while invoking api functions which
in turn may trigger the GC.
But the lesson is: when a heap becomes somehow corrupted, one can find the
effect well apart the
misbehaved code or object.
A corolary follows: never, never leave a collectable object without
reference, at least leave it in the stack, if you are going to refer to it
later.
The sequence of events and conditions leading to an object collection, even
if deterministic, is not
easily predictable ´by hand´.
So what works apparently OK in some context, may lead to a crash ( and a
very strange one )
in another, even if the two have minimal differences.
By the way, I learned about the smartness and efficiency of the GC:
iterating the same script thousands of times, the data segment of the
program remains stable. Good work !!!