search

jirentabu / crashrpt

Automatically exported from code.google.com/p/crashrpt
0 stars 0 forks source link

exit(1) in different thread may cause crashes #43

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?
0. Have a global class instance that the main thread uses
1. Install CrashRpt with SEH handler
2. Crash in a different thread
3. CrashRpt calls exit(1) in CCrashHandler::SehHandler, which destructs the 
global instance
4. The main thread crashes

Perhaps _exit() should be called instead.

See exit() and _exit() documentation:
http://msdn.microsoft.com/en-us/library/6wdz5232%28VS.90%29.aspx

0:004> ~
   0  Id: 260.156c Suspend: 0 Teb: 7ffdf000 Unfrozen
   1  Id: 260.16bc Suspend: 0 Teb: 7ffde000 Unfrozen
   2  Id: 260.4b0 Suspend: 0 Teb: 7ffdd000 Unfrozen
   3  Id: 260.1198 Suspend: 0 Teb: 7ffd9000 Unfrozen
.  4  Id: 260.d8c Suspend: 0 Teb: 7ffdc000 Unfrozen
0:004> ~0s
eax=13421670 ebx=00000000 ecx=00000002 edx=00000000 esi=000000f8 edi=00000000
eip=772164f4 esp=0012f72c ebp=0012f798 iopl=0         nv up ei pl zr na pe nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00200246
ntdll!KiFastSystemCallRet:
772164f4 c3              ret
0:000> k
ChildEBP RetAddr  
0012f728 77215e6c ntdll!KiFastSystemCallRet
0012f72c 754b179c ntdll!NtWaitForSingleObject+0xc
0012f798 76a9f003 KERNELBASE!WaitForSingleObjectEx+0x98
0012f7b0 76a9efb2 kernel32!WaitForSingleObjectExImplementation+0x75
0012f7c4 10003217 kernel32!WaitForSingleObject+0x12
0012f848 10006265 CrashRpt!CCrashHandler::LaunchCrashSender+0xc9 
[c:\users\ksmyth\documents\gme\gme\lib\crashrpt\crashrpt\src\crashhandler.cpp @ 
1347]
0012f87c 1000661e CrashRpt!CCrashHandler::GenerateErrorReport+0x1db 
[c:\users\ksmyth\documents\gme\gme\lib\crashrpt\crashrpt\src\crashhandler.cpp @ 
864]
0012f8b4 6ee2cd59 CrashRpt!CCrashHandler::SigsegvHandler+0x45 
[c:\users\ksmyth\documents\gme\gme\lib\crashrpt\crashrpt\src\crashhandler.cpp @ 
1667]
0012f8d4 004b8ac5 msvcr90!_XcptFilter+0x151 
[f:\dd\vctools\crt_bld\self_x86\crt\src\winxfltr.c @ 375]
0012f8e0 6ee2f594 GME!__tmainCRTStartup+0x18b 
[f:\dd\vctools\crt_bld\self_x86\crt\src\crtexe.c @ 603]
0012f8f4 6ee3155e msvcr90!_EH4_CallFilterFunc+0x12
0012f920 004b85e1 msvcr90!_except_handler4_common+0x8e
0012f940 772165f9 GME!_except_handler4+0x20
0012f964 772165cb ntdll!ExecuteHandler2+0x26
0012fa14 77216457 ntdll!ExecuteHandler+0x24
0012fa14 0049182a ntdll!KiUserExceptionDispatcher+0xf
0012fd38 00422ae0 GME!CGraphics::Uninitialize+0xa 
[e:\gmesrc\trunk\gme\gme\graphicsutil.cpp @ 179]
0012fee4 623e717d GME!CGMEApp::Run+0x180 [e:\gmesrc\trunk\gme\gme\gmeapp.cpp @ 
538]
0012fef8 004b8a7a mfc90!AfxWinMain+0x6a 
[f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\winmain.cpp @ 47]
0012ff88 76aa1174 GME!__tmainCRTStartup+0x140 
[f:\dd\vctools\crt_bld\self_x86\crt\src\crtexe.c @ 578]
0012ff94 7722b3f5 kernel32!BaseThreadInitThunk+0xe
0012ffd4 7722b3c8 ntdll!__RtlUserThreadStart+0x70
0012ffec 00000000 ntdll!_RtlUserThreadStart+0x1b
0:000> ~4s
eax=047bc758 ebx=00000000 ecx=623d9190 edx=000000eb esi=00507108 edi=00507108
eip=6241be18 esp=02eff6a8 ebp=02eff8d8 iopl=0         nv up ei pl nz na po nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00010202
mfc90!CWinApp::~CWinApp+0x4a:
6241be18 385814          cmp     byte ptr [eax+14h],bl      ds:0023:047bc76c=??
0:004> k
ChildEBP RetAddr  
02eff8d8 6258a8dd mfc90!CWinApp::~CWinApp+0x4a 
[f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\appcore.cpp @ 755]
02eff900 0042f6b8 mfc90!CWinAppEx::~CWinAppEx+0x10a 
[f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\afxwinappex.cpp @ 131]
02eff91c 6ede23b1 GME!CGMEApp::~CGMEApp+0x1b8 
[e:\gmesrc\trunk\gme\gme\gmeapp.cpp @ 150]
02eff960 6ede2466 msvcr90!doexit+0xab 
[f:\dd\vctools\crt_bld\self_x86\crt\src\crt0dat.c @ 591]
02eff974 10006348 msvcr90!exit+0x11 
[f:\dd\vctools\crt_bld\self_x86\crt\src\crt0dat.c @ 412]
02eff9ac 76ab2c2a CrashRpt!CCrashHandler::SehHandler+0x46 
[c:\users\ksmyth\documents\gme\gme\lib\crashrpt\crashrpt\src\crashhandler.cpp @ 
1391]
02effa34 77245a74 kernel32!UnhandledExceptionFilter+0x127
02effa3c 771ed950 ntdll!__RtlUserThreadStart+0x62
02effa50 771ed7ec ntdll!_EH4_CallFilterFunc+0x12
02effa78 772165f9 ntdll!_except_handler4+0x8e
02effa9c 772165cb ntdll!ExecuteHandler2+0x26
02effb4c 77216457 ntdll!ExecuteHandler+0x24
02effb4c 623d9132 ntdll!KiUserExceptionDispatcher+0xf
02effe80 623d86b4 mfc90!CThreadLocalObject::GetData+0x1f 
[f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\afxtls.cpp @ 412]
02efff44 6ede3433 mfc90!AfxGetModuleThreadState+0x16 
[f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\afxstate.cpp @ 498]
02efff7c 6ede34c7 msvcr90!_callthreadstartex+0x1b 
[f:\dd\vctools\crt_bld\self_x86\crt\src\threadex.c @ 348]
02efff88 76aa1174 msvcr90!_threadstartex+0x69 
[f:\dd\vctools\crt_bld\self_x86\crt\src\threadex.c @ 326]
02efff94 7722b3f5 kernel32!BaseThreadInitThunk+0xe
02efffd4 7722b3c8 ntdll!__RtlUserThreadStart+0x70
02efffec 00000000 ntdll!_RtlUserThreadStart+0x1b

Original issue reported on code.google.com by kevin.m....@gmail.com on 22 Jun 2010 at 4:26

GoogleCodeExporter commented 9 years ago

Original comment by zexspect...@gmail.com on 23 Jun 2010 at 12:22

GoogleCodeExporter commented 9 years ago 
I replaced exit() with ExitProcess()

Fixed in v.1.2.5.

Original comment by zexspect...@gmail.com on 26 Jun 2010 at 12:25

GoogleCodeExporter commented 9 years ago 
I don't think that solves the problem. TerminateProcess() should be called 
instead.

Test file:
#include <windows.h>

int main() {
    ExitProcess(1);
}

class tmp {
public:
    ~tmp() { 
        GetProcAddress(0, 0);
    }
} tmp1;

Callstack showing destructor is called:
>   ExitTesting.exe!`dynamic atexit destructor for 'tmp1''()  + 0x4 bytes   C++
    msvcr90.dll!doexit(int code=0x00000000, int quick=0x00000000, int retcaller=0x00000001)  Line 591   C
    msvcr90.dll!_cexit()  Line 427 + 0xb bytes  C
    msvcr90.dll!__CRTDLL_INIT(void * hDllHandle=0x6fb90000, unsigned long dwReason=0x00000000, void * lpreserved=0x00000001)  Line 328  C
    msvcr90.dll!_CRTDLL_INIT(void * hDllHandle=0x6fb90000, unsigned long dwReason=0x00000000, void * lpreserved=0x00000001)  Line 214 + 0xe bytes   C
    ntdll.dll!_LdrpCallInitRoutine@16()  + 0x14 bytes   
    ntdll.dll!_LdrShutdownProcess@0()  + 0x141 bytes    
    ntdll.dll!_RtlExitUserProcess@4()  + 0x74 bytes 
    kernel32.dll!75ba7363()     
    ExitTesting.exe!main()  Line 4 + 0x8 bytes  C++
    ExitTesting.exe!__tmainCRTStartup()  Line 586 + 0x17 bytes  C
    kernel32.dll!@BaseThreadInitThunk@12()  + 0x12 bytes    
    ntdll.dll!___RtlUserThreadStart@8()  + 0x27 bytes   
    ntdll.dll!__RtlUserThreadStart@8()  + 0x1b bytes    

It is possible that an object may be in a state where it is not safe to 
destruct, e.g. between delete this->member; and this->member = 0;

Original comment by kevin.m....@gmail.com on 1 Jul 2010 at 4:28

GoogleCodeExporter commented 9 years ago 
Will fix this in the next release.

Original comment by zexspect...@gmail.com on 2 Jul 2010 at 3:41

GoogleCodeExporter commented 9 years ago 
Fixed in v.1.2.6

Original comment by zexspect...@gmail.com on 9 Jul 2010 at 5:05