Dear Alexey, Many thanks for the detailed advise. In fact I have already fixed my application by calling a local substitute of GiNaC::remove_dirac_ONE(). Since scalarisation like x*ONE - > x (or checking if it is possible at all) is a rather common task, I thought a user can benefit from non-throwing version in GiNaC. But I am not insisting by any means. Shall I write a documentation patch advising a user to make cut&paste of the GiNaC code of remove_dirac_ONE() if they will meet this type of problem? Best wishes, Vladimir -- Vladimir V. Kisil http://www.maths.leeds.ac.uk/~kisilv/ Book: Geometry of Mobius Transformations http://goo.gl/EaG2Vu Software: Geometry of cycles http://moebinv.sourceforge.net/
On Sat, 08 Jun 2019 10:25:36 +0400, Alexey Sheplyakov <asheplyakov@yandex.ru> said:
ASh> Hi, ASh> 07.06.2019, 11:45, "Vladimir V. Kisil" ASh> <kisilv@maths.leeds.ac.uk>: >>>>>>> On Wed, 05 Jun 2019 20:51:10 +0100, "Vladimir V. Kisil" ASh> <kisilv@maths.leeds.ac.uk> said: >> VVK> Dear All, I finally managed to check Alexey's proposition to VVK> wrap the throwing remove_dirac_ONE function. It indeed prevents VVK> my Windows app from crashing. Thus I attach the respective VVK> light-weighted patches. >> >> Apology to everyone: the previously sent version had a debugging >> printout. The clean patch is attached now. ASh> I think the 1st and the 2nd patches are OK and can be applied. ASh> The one which adds a non-throwing remove_dirac_ONE() is much ASh> better too, however, I don't think adding non-throwing variant ASh> of every GiNaC method and function is a good idea. Instead I ASh> suggest to fix the application itself (more details below). >> Thanks for further comment. Before making the respective change >> to the patch I wish to discuss the crash. It is indeed look >> strange (and took time to debug), but presence of exception >> within the GiNaC library was not an issue, but calling those >> methods from another library produced a crash. I do not >> understand coding well, by my guess would be that a Qt >> application run each library in a separate thread ASh> Nope, Qt applications don't (and can't) do that >> and exceptions are fine within one tread. ASh> Not only it's not right, it's not even wrong. ASh> ELF (Linux' binaries/shared libraries files format) and PE/COFF ASh> (windows' executables/shared libraries format) use completely ASh> different paradigms for run-time loading of code. ASh> ELF shared library contains code to be used by the program, and ASh> also the names of functions and data that it expects to find in ASh> other shared libraries and/or the program. When the shared ASh> library A is joined to the program, all references to those ASh> functions and data in A's code are changed to point to the ASh> actual locations in other shared libraries and the program ASh> where the functions and data are placed in memory. This is ASh> basically a usual link operation. ASh> On the other hand PE/COFF shared library (DLL) is sort of ASh> self-contained: access to external functions and data goes ASh> through a lookup table (of that DLL). So the DLL code does not ASh> have to be fixed up at runtime to refer to the program’s ASh> memory; instead, the code already uses the DLL’s lookup table, ASh> and the lookup table is modified at runtime to point to the ASh> functions and data. ASh> The key difference is that each DLL has its own lookup table, ASh> and ELF has (sort of) a single lookup table for a whole ASh> program. ASh> Thus if a program uses two DLLs, A and B, malloc/free functions ASh> referenced by DLL A can be different from malloc/free functions ASh> used by DLL B. If such a program ends up allocating memory in ASh> DLL A and releasing it in DLL B, the result is (typically) a ASh> crash. ASh> A similar problem exists with C++ exceptions. The internal data ASh> used to find the matching catch block and perform stack ASh> unwinding are highly compiler-specific and may use global ASh> variables and heap. Thus if all DLLs aren't sharing C++ runtime ASh> cross-DLL exception (throwing an exception in DLL A and ASh> catching it in DLL B) is a problem (most likely crash). ASh> To recap: on windows exceptions are fine ASh> - within the same DLL - across DLLs sharing the same (C/C++) ASh> runtime ASh> Hope this helps, Alexey ASh> _______________________________________________ GiNaC-devel ASh> mailing list GiNaC-devel@ginac.de ASh> https://www.cebix.net/mailman/listinfo/ginac-devel