[Mingw-users] __mingwthr_run_key_dtors crash on exit

[David D. <dav...@rs...>]

At work, my team develops a cross platform application using GCC for =
every platform to make builds more smooth.  In the past week our windows =
build started crashing on exit.  I have tried to reproduce the problem =
in a small test program but I have been unsuccessful.  I have narrowed =
the problem down to a small section of code that when executed causes =
the program to crash on exit.  I then changed that section of code to be =
a lot simpler as a test..  The flow of the program goes something like =
this...


=20
There are major pieces to this transaction a host program (executable =
program) and an addin (shared object).
=20
Host makes a class available to addin via a registry (list of classes =
identified by name)
Addin grabs one of the classes from the registry and makes a call on it
That call throws an exception
=20
This transaction happens in the main thread.
=20



So under mingw, the EXE throws an exception and the DLL catches it.  For =
the simple test case I just have the EXE throwing an int and the DLL =
catching it.  As soon as this happens something breaks and whatever gets =
messed up only shows it's face when the application exits.  Both the =
application, the library and all the libraries they use are compiled =
with -mthreads.  The application launches a couple threads that stay =
running for most of the application, but are shut down well before the =
user closes the application.  The situation described above happens in =
the main thread.
=20
This program has been compiled on Linux x86, Linux x86_64 and mac =
without any problems.  Multiple runs through valgrind show no memory =
access problems and I am totally stumped because I can not get this =
behavior with the test program.  I do however realize that our software =
project is much larger and uses many shared objects loaded both =
dynamically and statically.
=20
Below is a trace and a little more information I got from GDB after =
compiling the MINGW runtime in debug mode.
=20
=20
Program received signal SIGSEGV, Segmentation fault.
0x02e99040 in ?? ()
=20
(gdb) bt
#0  0x02e99040 in ?? ()
#1  0x6fbc13fd in __mingwthr_run_key_dtors () at mthr.c:153
#2  0x6fbc14f1 in DllMain (hDllHandle=3D0x6fbc0000, reason=3D0, =
reserved=3D0x1)
    at mthr_init.c:68
#3  0x6fbc1089 in DllMainCRTStartup (hDll=3D0x6fbc0000, dwReason=3D0,
    lpReserved=3D0x1) at dllcrt1.c:87
#4  0x7c9011a7 in ntdll!LdrSetAppCompatDllRedirectionCallback () from =
ntdll.dll
=20
(gdb) f 1
#1  0x6fbc13fd in __mingwthr_run_key_dtors () at mthr.c:153
153                (*keyp->dtor) (value);
=20
(gdb) print keyp
$1 =3D (__mingwthr_key_t *) 0x4418160
=20
(gdb) print keyp->dtor
$2 =3D (void (*)()) 0x2e99040
=20
(gdb) print *keyp->dtor
Cannot access memory at address 0x2e99040
=20
(gdb) print *keyp
$3 =3D {key =3D 25, dtor =3D 0x2e99040, next =3D 0x2636360}
=20
As you can see, keyp->dtor appears to be invalid.  However, I do not =
know where this variable comes from.  It appears that these objects are =
created and destroyed to track something with threads, but I do not know =
what could cause one to be prematurely deleted (or added invalidly) as =
it would appear is happening.
=20
When I look at the source files for the runtime if I comment out the =
line that runs the dtors for when the PROCESS TERMINATES ONLY (not the =
thread ones) it does not crash, and since the process is ending it's not =
really a memory leak..  I don't like this solution though because it =
means I am doing something bad, or there is a bug.  Example below...
=20
case DLL_PROCESS_DETACH:
       __mingwthr_run_key_dtors();  //comment this line
       DeleteCriticalSection (&__mingwthr_cs);
      break;
=20
=20
I tried compiling gcc4.0.1 with mingw to see if this still happens, and =
was successful with the compilation.  However gcc4.0.1 has a bug and =
ICEs when compiling wxwidgets under windows, so I cannot complete the =
test with this version.
=20
If there is any other information I can provide please tell me.  If =
there are any known conditions under which this can happen please tell =
me.  I would really like to get this solved my fault or not.

Thank you for your time, it is greatly appreciated.

Sincerely,
David C. Daeschler