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 _______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
