Crash in __mingwthr_run_key_dtors?

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Crash in __mingwthr_run_key_dtors?

lollisoft
Hi,

I am using mingw since I use MiniCppUnit. My unit tests are run after
I load my DLL's that contain unit tests.
Loading and executing these tests works well and I got rid of DLL
dependencies by correctly unloading the DLL's in reverse order.

Even that; I'll get crashes. The crash is in __mingwthr_run_key_dtors
and I don't know to get rid of this.

Does anyone know how to avoid this?

I actually have no test throwing and also no signal is issued. Any
hints?

Thanks

Lothar

q:\develop\Projects\CPP\BaseDevelopment>gdb ..\..\bin
\lbDMFUnitTests.exe
GNU gdb 6.8.0.20080328-cvs (cygwin-special)
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/
gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show
copying"
and "show warranty" for details.
This GDB was configured as "i686-pc-cygwin"...
cygwin warning:
  MS-DOS style path detected: ..\..\bin\lbDMFUnitTests.exe
  Preferred POSIX equivalent is: ../../bin/lbDMFUnitTests.exe
  CYGWIN environment variable option "nodosfilewarning" turns off this
warning.
  Consult the user's guide for more details about POSIX paths:
    http://cygwin.com/cygwin-ug-net/using.html#using-pathnames
(gdb) run

...

+ BaseDevelopmentEventManager
  - BaseDevelopmentEventManager::test_Instanciate_lbEventmanager
  - BaseDevelopmentEventManager::test_lbEventmanager_Register_Event
  - BaseDevelopmentEventManager::test_lbEventmanager_Resolve_Event
  - BaseDevelopmentEventManager::test_UIWrapper_askYesNo_expext_yes
  - BaseDevelopmentEventManager::test_UIWrapper_askYesNo_expext_no
.test_Instanciate_lbEventmanager
.test_lbEventmanager_Register_Event
.test_lbEventmanager_Resolve_Event
.test_UIWrapper_askYesNo_expext_yes
Instance of lb_I_Application created
Registered event ID=12002 for askYesNo.
lbErrCodes LB_STDCALL UIWrapper::askYesNo(lb_I_Unknown* uk) called.
Console dialog:

Expect yes

y
.test_UIWrapper_askYesNo_expext_no
Instance of lb_I_Application created
Registered event ID=12002 for askYesNo.
lbErrCodes LB_STDCALL UIWrapper::askYesNo(lb_I_Unknown* uk) called.
Console dialog:

Expect no

n

Summary:
        Executed Tests: 46
        Passed Tests:   46
Unregister meta application.
Unregister unit tests.
Unload plugins.
Unloading module lbDynApp
Unloading module testsBaseDevelopment
Unloading module testsActions
Unloading module TestPlugin
Unloading module lbVisitorOperations
Unloading module lbLoginWizard
Unloading module lbDynamicAppStorage
Unloading module lbDB
Unloading module lbMetaApplication
Unloading module lbDMFXslt
Unloading module lbDMFDataModel
Unloading module lbDatabaseReport
Unloading module lbDatabaseForm
Unloading module lbCryptoStream
Unloading module FaxProxy
Unloading module DatabaseLayerGateway
Unloading module ApplicationBusProxy
Unloading module lbPluginManager
Unloading module lbClasses

Program received signal SIGSEGV, Segmentation fault.
0x6ce5a350 in ?? ()
(gdb) where
#0  0x6ce5a350 in ?? ()
#1  0x6fbc1383 in __mingwthr_run_key_dtors ()
   from /cygdrive/q/develop/Tools/mingw/bin/mingwm10.dll
#2  0x6fbc13c8 in DllMain@12 ()
   from /cygdrive/q/develop/Tools/mingw/bin/mingwm10.dll
#3  0x6fbc10ed in DllMainCRTStartup@12 ()
   from /cygdrive/q/develop/Tools/mingw/bin/mingwm10.dll
#4  0x7c91118a in ntdll!LdrSetAppCompatDllRedirectionCallback ()
   from /cygdrive/c/WINDOWS/system32/ntdll.dll
#5  0x6fbc0000 in ?? ()
#6  0x00000000 in ?? ()
(gdb)

------------------------------------------------------------------------------
Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
Be part of this innovative community and reach millions of netbook users
worldwide. Take advantage of special opportunities to increase revenue and
speed time-to-market. Join now, and jumpstart your future.
http://p.sf.net/sfu/intel-atom-d2d
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Reply | Threaded
Open this post in threaded view
|

Re: Crash in __mingwthr_run_key_dtors?

Greg Chicares
On 2010-08-29 14:26Z, Lothar Behrens wrote:
>
> I am using mingw since I use MiniCppUnit. My unit tests are run after
> I load my DLL's that contain unit tests.
> Loading and executing these tests works well and I got rid of DLL
> dependencies by correctly unloading the DLL's in reverse order.
>
> Even that; I'll get crashes. The crash is in __mingwthr_run_key_dtors
> and I don't know to get rid of this.

I'm not sure what MinGW version you use, but this might be relevant:

http://article.gmane.org/gmane.comp.gnu.mingw.user/16706/match=__mingwthr_run_key_dtors

Is it possible to leave the dlls loaded until the program terminates?

------------------------------------------------------------------------------
Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
Be part of this innovative community and reach millions of netbook users
worldwide. Take advantage of special opportunities to increase revenue and
speed time-to-market. Join now, and jumpstart your future.
http://p.sf.net/sfu/intel-atom-d2d
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Reply | Threaded
Open this post in threaded view
|

Re: Crash in __mingwthr_run_key_dtors?

lollisoft

Am 29.08.2010 um 18:59 schrieb Greg Chicares:

> On 2010-08-29 14:26Z, Lothar Behrens wrote:
>>
>> I am using mingw since I use MiniCppUnit. My unit tests are run after
>> I load my DLL's that contain unit tests.
>> Loading and executing these tests works well and I got rid of DLL
>> dependencies by correctly unloading the DLL's in reverse order.
>>
>> Even that; I'll get crashes. The crash is in __mingwthr_run_key_dtors
>> and I don't know to get rid of this.
>
> I'm not sure what MinGW version you use, but this might be relevant:

I have at least a version with g++ = 3.4.5 (mingw-vista special r3)

>
> http://article.gmane.org/gmane.comp.gnu.mingw.user/16706/match=__mingwthr_run_key_dtors
>
> Is it possible to leave the dlls loaded until the program terminates?
>

I am heavily rely on dynamic DLL loading. I wonder why my GUI application works fine and the unit tests will crash at exit. The unit tests it self will work fine - all tests are passing :-)

My flow is as follows:

I load a lbModule.dll that is responsible to load the rest. It contains a yet hard coded list of classes (interfaces names) that maps to DLL's and a entry point per interface.
That way I load subsequent classes such as even a string (lbclasses.dll). Then I probably load other stuff.

To ensure that the basic types in lbclasses are unloaded as last as possible I load it as first as possible. The code will look like this:

int main()
{
        int result = 0;
        {
                UAP_REQUEST(getModuleInstance(), lb_I_String, precreeatedToHoldTheDllAsLongAsPossible)
                UAP_REQUEST(getModuleInstance(), lb_I_PluginManager, PM)

                PM->initialize();

                result = theInstance().runTests() ? 0 : -1;

        printf("Unregister unit tests.\n");
        theInstance().unregisterTests();

        printf("Unload plugins.\n");
                PM->unload();
        }

        //setVerbose(true);
        printf("Unload all other modules.\n");
        unHookAll();
        //setVerbose(false);

        return result;
}

As I remember I had trouble with headers that contain implementation when using DLL's that are at least loaded at runtime. The code that gone to the executable (from the header) internally relied on code implemented in the DLL.
When the DLL get's unloaded I'll get a crash. I think this is the cause as of the MiniCppUnit library (a header) relies on code in the header and I think that will be the cause - design does not match my requirements :-(

Despite of modifying the library to allow explicitly destroy the various tests, I didn't got rid of the crash - it may have been changed to the least one with the __mingwthr_run_key_dtors. Before that my code crashed earlier I think.

I think I should write my own unit test library and drop the MiniCppUnit.

Lothar

> ------------------------------------------------------------------------------
> Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
> Be part of this innovative community and reach millions of netbook users
> worldwide. Take advantage of special opportunities to increase revenue and
> speed time-to-market. Join now, and jumpstart your future.
> http://p.sf.net/sfu/intel-atom-d2d
> _______________________________________________
> MinGW-users mailing list
> [hidden email]
>
> This list observes the Etiquette found at
> http://www.mingw.org/Mailing_Lists.
> We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.
>
> _______________________________________________
> You may change your MinGW Account Options or unsubscribe at:
> https://lists.sourceforge.net/lists/listinfo/mingw-users
>

-- | Rapid Prototyping | XSLT Codegeneration | http://www.lollisoft.de
Lothar Behrens
Ginsterweg 4
65760 Eschborn













------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Crash in __mingwthr_run_key_dtors?

lollisoft
Just a note:

I have figured out what was the cause of the crash (nearly). My unit tests contained a Sqlite test whose intention was to fail a SQL query. This caused the application to crash at the end.

Also I have replaced the static instance of MiniCppUnit (theInstance) to a non static version (Type* theInstance) and allocated it once. Also I have replaced the other static stuff that would
create a static instance per test registration.

I may ask the author about adding these new features :-)

Now I have to look at the only failing test.

Lothar

Am 09.07.2011 um 08:17 schrieb Lothar:

>
> Am 29.08.2010 um 18:59 schrieb Greg Chicares:
>
>> On 2010-08-29 14:26Z, Lothar Behrens wrote:
>>>
>>> I am using mingw since I use MiniCppUnit. My unit tests are run after
>>> I load my DLL's that contain unit tests.
>>> Loading and executing these tests works well and I got rid of DLL
>>> dependencies by correctly unloading the DLL's in reverse order.
>>>
>>> Even that; I'll get crashes. The crash is in __mingwthr_run_key_dtors
>>> and I don't know to get rid of this.
>>
>> I'm not sure what MinGW version you use, but this might be relevant:
>
> I have at least a version with g++ = 3.4.5 (mingw-vista special r3)
>
>>
>> http://article.gmane.org/gmane.comp.gnu.mingw.user/16706/match=__mingwthr_run_key_dtors
>>
>> Is it possible to leave the dlls loaded until the program terminates?
>>
>
> I am heavily rely on dynamic DLL loading. I wonder why my GUI application works fine and the unit tests will crash at exit. The unit tests it self will work fine - all tests are passing :-)
>
> My flow is as follows:
>
> I load a lbModule.dll that is responsible to load the rest. It contains a yet hard coded list of classes (interfaces names) that maps to DLL's and a entry point per interface.
> That way I load subsequent classes such as even a string (lbclasses.dll). Then I probably load other stuff.
>
> To ensure that the basic types in lbclasses are unloaded as last as possible I load it as first as possible. The code will look like this:
>
> int main()
> {
> int result = 0;
> {
> UAP_REQUEST(getModuleInstance(), lb_I_String, precreeatedToHoldTheDllAsLongAsPossible)
> UAP_REQUEST(getModuleInstance(), lb_I_PluginManager, PM)
>
> PM->initialize();
>
> result = theInstance().runTests() ? 0 : -1;
>
>         printf("Unregister unit tests.\n");
>         theInstance().unregisterTests();
>
>         printf("Unload plugins.\n");
> PM->unload();
> }
>
> //setVerbose(true);
> printf("Unload all other modules.\n");
> unHookAll();
> //setVerbose(false);
>
> return result;
> }
>
> As I remember I had trouble with headers that contain implementation when using DLL's that are at least loaded at runtime. The code that gone to the executable (from the header) internally relied on code implemented in the DLL.
> When the DLL get's unloaded I'll get a crash. I think this is the cause as of the MiniCppUnit library (a header) relies on code in the header and I think that will be the cause - design does not match my requirements :-(
>
> Despite of modifying the library to allow explicitly destroy the various tests, I didn't got rid of the crash - it may have been changed to the least one with the __mingwthr_run_key_dtors. Before that my code crashed earlier I think.
>
> I think I should write my own unit test library and drop the MiniCppUnit.
>
> Lothar
>
>> ------------------------------------------------------------------------------
>> Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
>> Be part of this innovative community and reach millions of netbook users
>> worldwide. Take advantage of special opportunities to increase revenue and
>> speed time-to-market. Join now, and jumpstart your future.
>> http://p.sf.net/sfu/intel-atom-d2d
>> _______________________________________________
>> MinGW-users mailing list
>> [hidden email]
>>
>> This list observes the Etiquette found at
>> http://www.mingw.org/Mailing_Lists.
>> We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.
>>
>> _______________________________________________
>> You may change your MinGW Account Options or unsubscribe at:
>> https://lists.sourceforge.net/lists/listinfo/mingw-users
>>
>
> -- | Rapid Prototyping | XSLT Codegeneration | http://www.lollisoft.de
> Lothar Behrens
> Ginsterweg 4
> 65760 Eschborn
>
>
>
>
>
>
>
>
>
>
>
>
>
> ------------------------------------------------------------------------------
> All of the data generated in your IT infrastructure is seriously valuable.
> Why? It contains a definitive record of application performance, security
> threats, fraudulent activity, and more. Splunk takes this data and makes
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2d-c2
> _______________________________________________
> MinGW-users mailing list
> [hidden email]
>
> This list observes the Etiquette found at
> http://www.mingw.org/Mailing_Lists.
> We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.
>
> _______________________________________________
> You may change your MinGW Account Options or unsubscribe at:
> https://lists.sourceforge.net/lists/listinfo/mingw-users
> Also: mailto:[hidden email]?subject=unsubscribe
>

-- | Rapid Prototyping | XSLT Codegeneration | http://www.lollisoft.de
Lothar Behrens
Ginsterweg 4
65760 Eschborn













------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Crash in __mingwthr_run_key_dtors?

lollisoft
It was the library that encapsulated the Sqlite database API and it was configured to throw exceptions. Changing this configuration solved the problem and may also be unrelated to any static class instances outside a function.

I have learned a lesson!

Thanks

Am 09.07.2011 um 09:56 schrieb Lothar:

> Just a note:
>
> I have figured out what was the cause of the crash (nearly). My unit tests contained a Sqlite test whose intention was to fail a SQL query. This caused the application to crash at the end.
>
> Also I have replaced the static instance of MiniCppUnit (theInstance) to a non static version (Type* theInstance) and allocated it once. Also I have replaced the other static stuff that would
> create a static instance per test registration.
>
> I may ask the author about adding these new features :-)
>
> Now I have to look at the only failing test.
>
> Lothar
>
> Am 09.07.2011 um 08:17 schrieb Lothar:
>
>>
>> Am 29.08.2010 um 18:59 schrieb Greg Chicares:
>>
>>> On 2010-08-29 14:26Z, Lothar Behrens wrote:
>>>>
>>>> I am using mingw since I use MiniCppUnit. My unit tests are run after
>>>> I load my DLL's that contain unit tests.
>>>> Loading and executing these tests works well and I got rid of DLL
>>>> dependencies by correctly unloading the DLL's in reverse order.
>>>>
>>>> Even that; I'll get crashes. The crash is in __mingwthr_run_key_dtors
>>>> and I don't know to get rid of this.
>>>
>>> I'm not sure what MinGW version you use, but this might be relevant:
>>
>> I have at least a version with g++ = 3.4.5 (mingw-vista special r3)
>>
>>>
>>> http://article.gmane.org/gmane.comp.gnu.mingw.user/16706/match=__mingwthr_run_key_dtors
>>>
>>> Is it possible to leave the dlls loaded until the program terminates?
>>>
>>
>> I am heavily rely on dynamic DLL loading. I wonder why my GUI application works fine and the unit tests will crash at exit. The unit tests it self will work fine - all tests are passing :-)
>>
>> My flow is as follows:
>>
>> I load a lbModule.dll that is responsible to load the rest. It contains a yet hard coded list of classes (interfaces names) that maps to DLL's and a entry point per interface.
>> That way I load subsequent classes such as even a string (lbclasses.dll). Then I probably load other stuff.
>>
>> To ensure that the basic types in lbclasses are unloaded as last as possible I load it as first as possible. The code will look like this:
>>
>> int main()
>> {
>> int result = 0;
>> {
>> UAP_REQUEST(getModuleInstance(), lb_I_String, precreeatedToHoldTheDllAsLongAsPossible)
>> UAP_REQUEST(getModuleInstance(), lb_I_PluginManager, PM)
>>
>> PM->initialize();
>>
>> result = theInstance().runTests() ? 0 : -1;
>>
>>       printf("Unregister unit tests.\n");
>>       theInstance().unregisterTests();
>>
>>       printf("Unload plugins.\n");
>> PM->unload();
>> }
>>
>> //setVerbose(true);
>> printf("Unload all other modules.\n");
>> unHookAll();
>> //setVerbose(false);
>>
>> return result;
>> }
>>
>> As I remember I had trouble with headers that contain implementation when using DLL's that are at least loaded at runtime. The code that gone to the executable (from the header) internally relied on code implemented in the DLL.
>> When the DLL get's unloaded I'll get a crash. I think this is the cause as of the MiniCppUnit library (a header) relies on code in the header and I think that will be the cause - design does not match my requirements :-(
>>
>> Despite of modifying the library to allow explicitly destroy the various tests, I didn't got rid of the crash - it may have been changed to the least one with the __mingwthr_run_key_dtors. Before that my code crashed earlier I think.
>>
>> I think I should write my own unit test library and drop the MiniCppUnit.
>>
>> Lothar
>>
>>> ------------------------------------------------------------------------------
>>> Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
>>> Be part of this innovative community and reach millions of netbook users
>>> worldwide. Take advantage of special opportunities to increase revenue and
>>> speed time-to-market. Join now, and jumpstart your future.
>>> http://p.sf.net/sfu/intel-atom-d2d
>>> _______________________________________________
>>> MinGW-users mailing list
>>> [hidden email]
>>>
>>> This list observes the Etiquette found at
>>> http://www.mingw.org/Mailing_Lists.
>>> We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.
>>>
>>> _______________________________________________
>>> You may change your MinGW Account Options or unsubscribe at:
>>> https://lists.sourceforge.net/lists/listinfo/mingw-users
>>>
>>
>> -- | Rapid Prototyping | XSLT Codegeneration | http://www.lollisoft.de
>> Lothar Behrens
>> Ginsterweg 4
>> 65760 Eschborn
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> All of the data generated in your IT infrastructure is seriously valuable.
>> Why? It contains a definitive record of application performance, security
>> threats, fraudulent activity, and more. Splunk takes this data and makes
>> sense of it. IT sense. And common sense.
>> http://p.sf.net/sfu/splunk-d2d-c2
>> _______________________________________________
>> MinGW-users mailing list
>> [hidden email]
>>
>> This list observes the Etiquette found at
>> http://www.mingw.org/Mailing_Lists.
>> We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.
>>
>> _______________________________________________
>> You may change your MinGW Account Options or unsubscribe at:
>> https://lists.sourceforge.net/lists/listinfo/mingw-users
>> Also: mailto:[hidden email]?subject=unsubscribe
>>
>
> -- | Rapid Prototyping | XSLT Codegeneration | http://www.lollisoft.de
> Lothar Behrens
> Ginsterweg 4
> 65760 Eschborn
>
>
>
>
>
>
>
>
>
>
>
>
>
> ------------------------------------------------------------------------------
> All of the data generated in your IT infrastructure is seriously valuable.
> Why? It contains a definitive record of application performance, security
> threats, fraudulent activity, and more. Splunk takes this data and makes
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2d-c2
> _______________________________________________
> MinGW-users mailing list
> [hidden email]
>
> This list observes the Etiquette found at
> http://www.mingw.org/Mailing_Lists.
> We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.
>
> _______________________________________________
> You may change your MinGW Account Options or unsubscribe at:
> https://lists.sourceforge.net/lists/listinfo/mingw-users
> Also: mailto:[hidden email]?subject=unsubscribe
>

-- | Rapid Prototyping | XSLT Codegeneration | http://www.lollisoft.de
Lothar Behrens
Ginsterweg 4
65760 Eschborn













------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe