Hi,

 

07.06.2019, 11:45, "Vladimir V. Kisil" <kisilv@maths.leeds.ac.uk>:

>>>>>>  On Wed, 05 Jun 2019 20:51:10 +0100, "Vladimir V. Kisil" <kisilv@maths.leeds.ac.uk> said:

>

>     VVK> Dear All, I finally managed to check Alexey's

>     VVK> proposition to wrap the throwing remove_dirac_ONE function. It

>     VVK> indeed prevents my Windows app from crashing. Thus I attach the

>     VVK> respective light-weighted patches.

>

>     Apology to everyone: the previously sent version had a debugging

>   printout. The clean patch is attached now.

 

I think the 1st and the 2nd patches are OK and can be applied.

The one which adds a non-throwing remove_dirac_ONE() is much better too, however,

I don't think adding non-throwing variant of every GiNaC method and function is a good idea.

Instead I 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

 

Nope, Qt applications don't (and can't) do that

 

>  and exceptions are fine within one tread.

 

Not only it's not right, it's not even wrong.

 

ELF (Linux' binaries/shared libraries files format) and PE/COFF (windows' executables/shared

libraries format) use completely different paradigms for run-time loading of code.

 

ELF shared library contains code to be used by the program, and also the names of functions

and data that it expects to find in other shared libraries and/or the program.

When the shared library A is joined to the program, all references to those functions and data

in A's code are changed to point to the actual locations in other shared libraries and the program

where the functions and data are placed in memory. This is basically a usual link operation.

 

On the other hand PE/COFF shared library (DLL) is sort of self-contained: access to external

functions and data goes through a lookup table (of that DLL). So the DLL code does not have

to be fixed up at runtime to refer to the program’s memory; instead, the code already uses

the DLL’s lookup table, and the lookup table is modified at runtime to point to the functions and data.

 

The key difference is that each DLL has its own lookup table, and ELF has (sort of) a single lookup

table for a whole program.

 

Thus if a program uses two DLLs, A and B, malloc/free functions referenced by DLL A can be

different from malloc/free functions used by DLL B. If such a program ends up allocating memory

in DLL A and releasing it in DLL B, the result is (typically) a crash.

 

A similar problem exists with C++ exceptions. The internal data used to find the matching

catch block and perform stack unwinding are highly compiler-specific and may use global

variables and heap. Thus if all DLLs aren't sharing C++ runtime cross-DLL exception (throwing

an exception in DLL A and catching it in DLL B) is a problem (most likely crash).

 

To recap: on windows exceptions are fine

 

Hope this helps,

        Alexey