Re: [fpc-pascal] Shared libraries and threadvars
Can such an alternative entry point in the main unit be called by a shared library, i.e. either resolved at load time or with the main binary reopened like a library? Or is the only way to pass a main- program entry point to a shared library by using it as a parameter to a procedure? I can't tell you for *nix systems as I'm not experienced enough regarding their dynamic linkers, Superficial testing suggests that if the code in a .so (Linux, i386) tries to call an extra entry point exported from the main program, that a run-time (libdl) load of the library will fail. I'll keep on tinkering with this, I've not yet retrieved the exact error message and I'm interested in seeing what happens if the .so itself tries to use libdl to reopen the main program. -- 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
[fpc-pascal] Error message: No matching implementation for interface method ...
I'm getting the below error messages and I suspect virtualstringtree / VirtualTrees.pas is the cause. The virtualtrees.pas line it objects to is: TVTDragManager = class(TInterfacedObject, IVTDragManager, IDropSource, IDropTarget) C:\development\lazarus\components\VirtualTreeView\VirtualTrees.pas(1029,20) Error: No matching implementation for interface method IDropSource.QueryContinueDrag(LongBool,LongWord):LongInt; StdCall; found C:\development\lazarus\components\VirtualTreeView\VirtualTrees.pas(1029,20) Error: No matching implementation for interface method IDropSource.GiveFeedback(LongWord):LongInt; StdCall; found C:\development\lazarus\components\VirtualTreeView\VirtualTrees.pas(1225,14) Warning: An inherited method is hidden by TVirtualTreeColumn.Equals(TObject):Boolean; Any suggestions how I might fix the issue? Using Laz 1.1 w/fpc 2.6.1 [2012/06/26] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Shared libraries and threadvars
Mark Morgan Lloyd wrote: Can such an alternative entry point in the main unit be called by a shared library, i.e. either resolved at load time or with the main binary reopened like a library? Or is the only way to pass a main- program entry point to a shared library by using it as a parameter to a procedure? I can't tell you for *nix systems as I'm not experienced enough regarding their dynamic linkers, Superficial testing suggests that if the code in a .so (Linux, i386) tries to call an extra entry point exported from the main program, that a run-time (libdl) load of the library will fail. I'll keep on tinkering with this, I've not yet retrieved the exact error message and I'm interested in seeing what happens if the .so itself tries to use libdl to reopen the main program. Short answer: works on Linux, but at run- (not load-time) only. Longer answer: if a .so has an explicit dependency on the main program, i.e. a procedure marked extern, an attempt to load it using dlopen(...RTLDLAZY) will fail (return zero as a handle). The error message refers to an entry point of the form library_proc_types rather than program_proc_types, and I've not managed to override that using extern or extern/name in a way that makes everything happy. Using LoadLibrary() - dlopen() inside the .so, passing an *empty* string representing the main program, appears to allow exported entry points to be accessed (i.e. a shared library can access a procedure in the main program in exactly the same way that a main program can access a procedure in a shared library). One thing that would be useful would be if DynLibs had a get last error function. I've implemented this myself for Linux and Windows and find it indispensable. -- 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
[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
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
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
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
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
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
[fpc-pascal] Re: Unhandled exception from library crashes host exe
On 27-6-2012 16:22, Antonio Fortuny wrote: 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. Would compiling FPC with the SEH exception handling code (-dTEST_WIN64_SEH) instead of that unit work in this context? It worked for me with Win64 embedded (i.e. dll+exe in same memory space) when dealing with exceptions inside the FB dll that incorrectly bubbled up to the exe. Unfortunately I don't know enough to tell if this would also improve FPU exception behaviour... See e.g. last comment in this bug: http://bugs.freepascal.org/view.php?id=21581 Thanks, Reinier ___ 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
