Re: [fpc-pascal] Unhandled exception from library crashes host exe
kyan wrote on Thu, 28 Jun 2012: On Thu, Jun 28, 2012 at 12:45 PM, Jonas Maebe wrote: The safecall calling convention is only supported on a few platforms. I want it for Win32/64, WinCE/arm and Linux. How can I find whether it is implemented on these platforms without having to actually test it? You have to look for tf_safecall_exceptions in systems/i_*.pas. It's currently supported for all Windows platforms and for Linux/i386 and Linux/x86-64. Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Unhandled exception from library crashes host exe
On Thu, Jun 28, 2012 at 12:45 PM, Jonas Maebe wrote: > The safecall calling convention is only supported on a few platforms. > Originally it was only supported on Windows. Nowadays it's also supported on > a few extra platforms because it was required for XPCOM (someone wanted to > use XPCOM on certain platforms, and only added suppport for safecall on > those particular platforms), but it's definitely not yet supported > everywhere. I'm also not aware of anyone planning on adding support for > safecall on other platforms. I want it for Win32/64, WinCE/arm and Linux. How can I find whether it is implemented on these platforms without having to actually test it? I went so far as to see that fpc_safecallcheck that calls the SafeCallErrorProc callback exists in system.inc but could not find where it is called. Thanks in advance. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Unhandled exception from library crashes host exe
kyan wrote on Thu, 28 Jun 2012: 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. The safecall calling convention is only supported on a few platforms. Originally it was only supported on Windows. Nowadays it's also supported on a few extra platforms because it was required for XPCOM (someone wanted to use XPCOM on certain platforms, and only added suppport for safecall on those particular platforms), but it's definitely not yet supported everywhere. I'm also not aware of anyone planning on adding support for safecall on other platforms. Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Unhandled exception from library crashes host exe
On Wed, Jun 27, 2012 at 8:15 PM, Sven Barth 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. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Unhandled exception from library crashes host exe
Apologies for my poor threading. Sven said: > Unix based systems might be a different topic altogether. I've no > experience regarding cross module excetions on *nix, so I can't > comment whether it works or not... > 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... Forcing an integer divide-by-zero error in a routine in a .so on i386 Linux, with an exception handler in the main program, I get a floating point error reported in the shell session. So it's definitely not trapped, and might be mis-reported. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Unhandled exception from library crashes host exe
Am 27.06.2012 15:59 schrieb "kyan" : > > I am sure that this has been asked before but I couldn't find an answer. > > I am in the process of porting a large application consisting of an > exe and many dlls from Delphi7 to FPC 2.7.1/Lazarus for Windows/WinCE > with hopes of being able to finally port it to Linux. I have managed > to overcome all obstacles but this seems like a brick wall: An > exception raised from a dll that is not handled by the dll's code will > crash the exe, bypassing any try/finally/except handlers around the > call into the dll that raised it. This is of course a complete > showstopper because the API and code of the dlls is way too massive to > re-engineer so that it does not let exceptions bubble up to the exe. > > In Delphi without packages the aforementioned situation can be handled > reasonably well because despite the fact that operators "is" and "as" > won't work on the dll's Exception object (its class pointer points > inside the dll's Exception class and not the exe's Exception class) at > least the exception handlers work so one can display an error message > and keep the main application loop running. It is solved perfectly if > one builds all executables with runtime packages so that there is only > one Exception class for the exe and all dlls. But in FPC there are no > "runtime packages" in the Delphi sense, therefore there doesn't seem > to be a solution to this. The problem is the following: the exception mechanism in FPC is implemented in a FPC-only way and only interfaces with the OS at certain points. To be more precise in Windows we use the API SetUnhandledExceptionFilter which registers a callback function with the OS which is called once an exception anywhere in the program (this includes DLLs) happens that is not handled by a SEH handler. FPC does not support such SEH handlers, thus if an exception is raised in a DLL (and here more especially an external, non-FPC exception) the unhandled exception handler callback is called which tries to find a fitting FPC except handler. I don't know the exact implementation of the handler, but it might be that it either ignores exceptions which happened in loaded DLLs (which leads to Windows terminating the process) or terminates the process itself. On Win64 it was started to support Windows' SEH (you need to build complete trunk with "-dTEST_WIN64_SEH" to enable it), but this won't help you for Win32 and WinCE. Adding support for WinCE on ARM might be rather easy though (maybe not for you, but for someone experienced with the topic) as it has a similar scheme as Win64. Win32 uses a different approach though, so this will no be that easy... Unix based systems might be a different topic altogether. I've no experience regarding cross module excetions on *nix, so I can't comment whether it works or not... > Can someone suggest a solution, even if I have to manually apply a > patch to FPC and build it myself? Because if there isn't one I will > have to scrap the whole project. You could try to fiddle around with the unhandled exception handler callback in the system unit, but I can't help you there... Nevertheless you need to search for SetUnhandledExceptionFilter in %fpcdir%\rtl\win32 and then look for the function that is given there as an argument. 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... Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Unhandled exception from library crashes host exe
Thank you all for your replies. > Regular exceptions, those raised with the "raise" keyword are always trapped > by try..except blocks but you have to make sure that EVERY method in the DLL > that is called by the host exe has such a construct so as not to let the > exception escape. As I already mentioned this is not an option for me within my given time frame. I am talking about an application with more than 20 dlls, hundreds of thousands of lines of code and a heavy API between exe and dlls based on interfaces. Even if I decided to bite the bullet and -for instance- turn every interface method to "safecall" and add "safecall" functionality in every object -I suppose that this would do the trick- this would take a considerable amount of time, unacceptable for production code that gets a release with new features every couple of weeks. > However, there are exceptions that come from the FPU and that arise when > doing floating point maths. Those, in a DLL, are not trapped by the > try..except blocks and are passed back to the host exe, effectively crashing > them. > If you want to trap them, you have to add a special unit in your DLL > project, as explained in this issue: > > http://bugs.freepascal.org/view.php?id=12974 > > Look for the last comment, it works fine here I've read it and it seems to work for AVs and FPU exceptions only, not for application-defined exceptions, is this correct? If so then it will not be enough for me I'm afraid. > That will not help. The problem described there appears only on Win64. > Not on Windows 32 or linux. Actually I am compiling with the 32bit version of FPC/Lazarus producing 32bit images but running in a Windows 7 64-bit OS. I am not sure if the problem appears in Win64 even with 32bit code. I can only confirm that the situation is exactly the same in WinCE. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Unhandled exception from library crashes host exe
Le 27/06/2012 16:14, OBones a écrit : Hello, Regular exceptions, those raised with the "raise" keyword are always trapped by try..except blocks but you have to make sure that EVERY method in the DLL that is called by the host exe has such a construct so as not to let the exception escape. However, there are exceptions that come from the FPU and that arise when doing floating point maths. Those, in a DLL, are not trapped by the try..except blocks and are passed back to the host exe, effectively crashing them. If you want to trap them, you have to add a special unit in your DLL project, as explained in this issue: http://bugs.freepascal.org/view.php?id=12974 I read quickly the las post and seems encouraging. I'll try it in my UDF (64bit, windows, Michael is right) and report any discrepancy but not before next week. Look for the last comment, it works fine here Regards ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Unhandled exception from library crashes host exe
On Wed, 27 Jun 2012, Antonio Fortuny wrote: Le 27/06/2012 15:58, kyan a écrit : I am sure that this has been asked before but I couldn't find an answer. I am in the process of porting a large application consisting of an exe and many dlls from Delphi7 to FPC 2.7.1/Lazarus for Windows/WinCE with hopes of being able to finally port it to Linux. I have managed to overcome all obstacles but this seems like a brick wall: An exception raised from a dll that is not handled by the dll's code will crash the exe, bypassing any try/finally/except handlers around the call into the dll that raised it. This is of course a complete showstopper because the API and code of the dlls is way too massive to re-engineer so that it does not let exceptions bubble up to the exe. Got the same with UDFs for FIrebird. Read two Firebird bugs: http://62.166.198.202/view.php?id=12974 and http://62.166.198.202/view.php?id=17280 they appear to be intimately related. That will not help. The problem described there appears only on Win64. Not on Windows 32 or linux. I suspect the problem will not appear on Linux because the library system is slightly different to windows; but Win32, I am not sure. I am not sure the problem can be solved correctly with the compiler as-is, but the compiler people should confirm or deny this. Michael.___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Unhandled exception from library crashes host exe
Hello, Regular exceptions, those raised with the "raise" keyword are always trapped by try..except blocks but you have to make sure that EVERY method in the DLL that is called by the host exe has such a construct so as not to let the exception escape. However, there are exceptions that come from the FPU and that arise when doing floating point maths. Those, in a DLL, are not trapped by the try..except blocks and are passed back to the host exe, effectively crashing them. If you want to trap them, you have to add a special unit in your DLL project, as explained in this issue: http://bugs.freepascal.org/view.php?id=12974 Look for the last comment, it works fine here Regards ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Unhandled exception from library crashes host exe
Le 27/06/2012 15:58, kyan a écrit : I am sure that this has been asked before but I couldn't find an answer. I am in the process of porting a large application consisting of an exe and many dlls from Delphi7 to FPC 2.7.1/Lazarus for Windows/WinCE with hopes of being able to finally port it to Linux. I have managed to overcome all obstacles but this seems like a brick wall: An exception raised from a dll that is not handled by the dll's code will crash the exe, bypassing any try/finally/except handlers around the call into the dll that raised it. This is of course a complete showstopper because the API and code of the dlls is way too massive to re-engineer so that it does not let exceptions bubble up to the exe. Got the same with UDFs for FIrebird. Read two Firebird bugs: http://62.166.198.202/view.php?id=12974 and http://62.166.198.202/view.php?id=17280 they appear to be intimately related. In Delphi without packages the aforementioned situation can be handled reasonably well because despite the fact that operators "is" and "as" won't work on the dll's Exception object (its class pointer points inside the dll's Exception class and not the exe's Exception class) at least the exception handlers work so one can display an error message and keep the main application loop running. It is solved perfectly if one builds all executables with runtime packages so that there is only one Exception class for the exe and all dlls. But in FPC there are no "runtime packages" in the Delphi sense, therefore there doesn't seem to be a solution to this. Can someone suggest a solution, even if I have to manually apply a patch to FPC and build it myself? Because if there isn't one I will have to scrap the whole project. Thank you in advance. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Unhandled exception from library crashes host exe
I am sure that this has been asked before but I couldn't find an answer. I am in the process of porting a large application consisting of an exe and many dlls from Delphi7 to FPC 2.7.1/Lazarus for Windows/WinCE with hopes of being able to finally port it to Linux. I have managed to overcome all obstacles but this seems like a brick wall: An exception raised from a dll that is not handled by the dll's code will crash the exe, bypassing any try/finally/except handlers around the call into the dll that raised it. This is of course a complete showstopper because the API and code of the dlls is way too massive to re-engineer so that it does not let exceptions bubble up to the exe. In Delphi without packages the aforementioned situation can be handled reasonably well because despite the fact that operators "is" and "as" won't work on the dll's Exception object (its class pointer points inside the dll's Exception class and not the exe's Exception class) at least the exception handlers work so one can display an error message and keep the main application loop running. It is solved perfectly if one builds all executables with runtime packages so that there is only one Exception class for the exe and all dlls. But in FPC there are no "runtime packages" in the Delphi sense, therefore there doesn't seem to be a solution to this. Can someone suggest a solution, even if I have to manually apply a patch to FPC and build it myself? Because if there isn't one I will have to scrap the whole project. Thank you in advance. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
