A huge thanks to Jonas for fixing issue 12704. I'm going to grab a copy of the trunk and compile it just so I can try this out. Thank you so much!

http://svn.freepascal.org/cgi-bin/viewvc.cgi?view=rev&revision=13077

Is there any chance of this being merged into the 2.2.x fixes branch? Or will this first see the light of day in 2.4.0?

Thanks again,

SG

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

Seth Grover wrote

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:

That's not possible. Per process, Unix only supports a single signal handler to be installed for a particular signal at any time. Moreover, Kylix nor FPC call through to previously installed signal handlers (even though they do record them, so you can restore them via the UnhookSignal() routine).

fpcprog does it as part of the sysutils initialization code,

Now the program has hooked them and will raise Pascal exceptions based on those signals.

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.

Then the last loaded library will have hooked them and raise the exceptions.

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.

For this you need Delphi-style "packages" support. That has nothing to do with the patch you are talking about (and if there were packages support, that patch would have changed nothing).

The problem you have right now is that the program and each of your libraries each contain their own copy of the exception class, and therefore do not recognise (Pascal) exceptions raised by any of the others. The Pascal exceptions will always be raised by the last one of those to hook the signal handlers.

With packages, only one single copy of the exception class could be included in the process (the one inside a package), and everyone would use that one. Therefore, regardless of who would translate the signal into an exception, everyone would recognise this exception instance for what it is.

Jonas

Jonas,

Thank you very much for the explanation.

-SG

Jonas Maebe wrote

The problem you have right now is that the program and each of your libraries each contain their own copy of the exception class, and therefore do not recognise (Pascal) exceptions raised by any of the others.

Well, that and the fact that moreover each library/program contains its own exception stack rather than a single shared one (although that could in theory already be solved by implementing eh-frame-based exception handling. Not that this would be so much easier than implementing packages support. Neither is particularly trivial.

Jonas

Aren't both problems solved by using the same RTL binary code (in library form)?

Micha

In our previous episode, Micha Nelissen said:

That is what the basis of packages is more or less. All code (including VMTs etc) only existing once, and a initialization order that matches the requirements of the unit initialization order.

IOW packages is just an automatable (for the compiler) of such system. More like how you compile a mainprogram with the compiler in one go instead of sorting the different .o's and passing cmds to the linker.

Yes, that's exactly what those packages are, afaik: http://wiki.freepascal.org/packages

I also think that ELF-style dynamic libraries are "natively" quite close already to the packages concept (unlike Windows dll's or Mac OS X shared libraries), but I don't know whether it's enough. And at least compiling the (linux) rtl into a shared library currently does not work: http://bugs.freepascal.org/view.php?id=12492 (and I think if you'd solve those problems, there would be others).

Jonas