[fpc-pascal] re: thanks for major signal handling fix

[Seth Grover]

Actually, looking closer at this fix (bug 12704, fixed in rev 13077),
it might not be exactly what I was expecting it to be. Maybe somebody
could clear up something I've been thinking about for a while now.

Imagine this scenario. I have an FPC-compiled executable (fpcprog) and
two FPC-compiled shared object libraries (libfpc1.so and libfpc2.so).
Each of which installs its own set of signal handlers: fpcprog does it
as part of the sysutils initialization code, and the .so's do it
(since rev 13077 was checked up) in "HookSignal(RTL_SIGDEFAULT)",
which (I suppose?) I would call during the libraries initialization
code.

Given this scenario, I would like any fatal signals (SIGSEGV, SIGILL,
etc.) to be handled in the correct try/except block in whatever binary
it might occur. So, for example, if I get a SIGSEGV in fpcprog, I want
it to be handled in the try/except block in fpcprog. If fpcprog calls
a routine in libfpc1.so, which causes a SIGSEGV, I want it to be
handled by the try/except block in that routine. if fpcprog calls a
routine in libfpc1.so, which in turn calls a routine in libfpc2.so,
which causes a SIGSEGV, I want it to be handled by the try/except
block in *that* routine, etc., etc. In my wildest dreams if I had an
access violation in libfpc2.so which wasn't in any try/except block,
I'd even love for it to be handled by the enclosing libfpc1.so
try/except block, but that's not really a requirement for me. As long
as all SIGSEGVs are handled by the try/except block in whatever binary
it happens to occur in, I'd be

Reading the comments for bug 12704 and the notes for revision 13077, I
assumed that that was what was going to happen, as I seem to recall it
worked that way in Kylix. But it still doesn't seem to work that way.
I have a C program (with no signal handlers) which uses my two .so's
in this example. If I call HookSignal in the .so initialization code,
libfpc2.so gets called first, then libfpc1.so. When libfpc1.so calls
libfpc2.so and causes and access violation, it's libfpc1.so's
try/except block which catches it (I assume since it's HookSignal was
the most recent one called). If I put the HookSignal calls in routines
rather than in the initialization code, causing libfpc1.so to call
HookSignal first, then libfpc2.so, and then cause an access violation
in libfpc1.so, NO signal handler catches it.

Is this a pipe dream? Or can I somehow make it work the way I'm expecting it?

If needed, I could provide some example projects.

Thanks,

SG

--
This email is fiction. Any resemblance to actual events
or persons living or dead is purely coincidental.

Seth Grover
sethdgrover[at]gmail[dot]com