[fpc-pascal] Unhandled exception from library crashes host exe

kyan alfasud.ti at gmail.com
Thu Jun 28 11:32:59 CEST 2012


On Wed, Jun 27, 2012 at 8:15 PM, Sven Barth <pascaldragon at googlemail.com> wrote:
> Summa summarum: don't let exceptions travel past the DLL boundary. One might
> be able to fix it on Windows, but *nix maybe not so much...

Thank you for your reply Sven.

It seem that the way to go -I don't have much knowledge on SEH so I'd
rather not mess with such low level system code- is to try to turn my
API to safecall and install a SafeCallErrorProc handler that will try
to recreate and raise the safecall exception from the callee module to
the caller one, which will eventually bubble up to the exe and the
main message loop. From what I've seen the safecall exception is not
based on any OS functionality but it is implemented by "compiler
magic" therefore I expect it to work (at least for application-defined
exceptions) in all OSes.

As I see it, if all interface methods exposed by a dll are safecall no
exception will cross dll boundaries since it will be trapped by the
compiler-generated safecall "try-finally" code and jump to
TObject.SafeCallException() which must be overridden to pass the
exception data to some sort of global storage. Then I will have to
install a SafeCallErrorProc callback that will poll the global storage
and reraise an exception based on the data placed there by
TObject.SafeCallException(). This way no Exception descendant will
ever pass any dll boundary and chaining is possible (exe calls dll1
which calls dll2 which raises an exception, dll2 traps it, places it
in the global storage, dll1 reraises it in its SafeCallErrorProc and
traps it and places it again in the global storage and exe reraises it
in its SafeCallErrorProc). The only difficulties are that the global
storage must be singleton to all modules (shared memory f.ex.) and
must have separate storage per thread. Just like COM/OLE does it with
the IErrorInfo object.

It is a good thing that my API is based on interfaces and not on
regular exported functions -except for a "factory" function that never
raises an exception and all objects whose methods cross dll boundaries
have 2 or 3 common ancestors.



More information about the fpc-pascal mailing list