<div>Hi,</div><div> </div><div>07.06.2019, 11:45, "Vladimir V. Kisil" <kisilv@maths.leeds.ac.uk>:</div><div>>>>>>>  On Wed, 05 Jun 2019 20:51:10 +0100, "Vladimir V. Kisil" <kisilv@maths.leeds.ac.uk> said:</div><div>></div><div>>     VVK> Dear All, I finally managed to check Alexey's</div><div>>     VVK> proposition to wrap the throwing remove_dirac_ONE function. It</div><div>>     VVK> indeed prevents my Windows app from crashing. Thus I attach the</div><div>>     VVK> respective light-weighted patches.</div><div>></div><div>>     Apology to everyone: the previously sent version had a debugging</div><div>>   printout. The clean patch is attached now.</div><div> </div><div>I think the 1st and the 2nd patches are OK and can be applied.</div><div>The one which adds a non-throwing remove_dirac_ONE() is much better too, however,</div><div>I don't think adding non-throwing variant of every GiNaC method and function is a good idea.</div><div>Instead I suggest to fix the application itself (more details below).</div><div> </div><div>>        Thanks for further comment. Before making the respective change</div><div>>  to the patch I wish to discuss the crash. It is indeed look strange</div><div>>  (and took time to debug), but presence of exception within the GiNaC</div><div>>  library was not an issue, but calling those methods from another</div><div>>  library produced a crash. I do not understand coding well, by my guess</div><div>>  would be that a Qt application run each library in a separate thread</div><div> </div><div>Nope, Qt applications don't (and can't) do that</div><div> </div><div>>  and exceptions are fine within one tread.</div><div> </div><div>Not only it's not right, it's not even wrong.</div><div><br /> </div><div>ELF (Linux' binaries/shared libraries files format) and PE/COFF (windows' executables/shared</div><div>libraries format) use completely different paradigms for run-time loading of code.</div><div> </div><div>ELF shared library contains code to be used by the program, and also the names of functions</div><div>and data that it expects to find in other shared libraries and/or the program.</div><div>When the shared library A is joined to the program, all references to those functions and data</div><div>in A's code are changed to point to the actual locations in other shared libraries and the program</div><div>where the functions and data are placed in memory. This is basically a usual link operation.</div><div> </div><div>On the other hand PE/COFF shared library (DLL) is sort of self-contained: access to external</div><div>functions and data goes through a lookup table (of that DLL). So the DLL code does not have</div><div>to be fixed up at runtime to refer to the program’s memory; instead, the code already uses</div><div>the DLL’s lookup table, and the lookup table is modified at runtime to point to the functions and data.</div><div> </div><div>The key difference is that each DLL has its own lookup table, and ELF has (sort of) a single lookup</div><div>table for a whole program.</div><div> </div><div>Thus if a program uses two DLLs, A and B, malloc/free functions referenced by DLL A can be</div><div>different from malloc/free functions used by DLL B. If such a program ends up allocating memory</div><div>in DLL A and releasing it in DLL B, the result is (typically) a crash.</div><div> </div><div>A similar problem exists with C++ exceptions. The internal data used to find the matching</div><div>catch block and perform stack unwinding are highly compiler-specific and may use global</div><div>variables and heap. Thus if all DLLs aren't sharing C++ runtime cross-DLL exception (throwing</div><div>an exception in DLL A and catching it in DLL B) is a problem (most likely crash).</div><div> </div><div>To recap: on windows exceptions are fine<div> </div><div>- within the same DLL</div><div>- across DLLs sharing the same (C/C++) runtime</div><div> </div></div><div> </div><div>Hope this helps,</div><div>        Alexey</div><div> </div>