C++11标准库新增的std::thread类可以方便地开启子线程。然而有个奇怪的现象是，如果在这些子线程中抛出了未处理的C++异常而导致程序崩溃，那么在生成的dump文件中将还原不出异常发生时的调用栈。可以通过下面的方法来展示这个现象。
首先使用以下代码生成一个控制台程序：
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 #include <thread> #include <vector> std::thread* g_thread; void ThreadEntry () std::vector<int > v; v.at (0 ); } int main () g_thread = new std::thread (ThreadEntry); g_thread->join (); }
这段代码很简单，就是通过std::thread创建一个子线程，并且在这个子线程中访问一个空的std::vector中的元素，让它抛出C++异常。务必要使用Release配置来生成程序，不能使用Debug配置。
接下来，在资源管理器中直接运行该程序，注意不要通过调试器来运行。一般会在第二次运行的时候，出现下面的Windows错误报告窗口：
在详细信息中的C:\Users\Zplutor\AppData\Local\Temp\WERBF98.tmp.mdmp文件即是Windows错误报告为崩溃的程序生成的dump文件，里面包含了程序崩溃时的一些信息，例如函数调用栈。该文件在关闭了错误报告窗口时即被删除，所以要先把这个文件复制出来。
最后，用WinDbg打开这个dump文件，先用.ecxr命令切换到异常环境，再用k命令显示调用栈，结果显示如下：
1 2 3 4 5 6 7 8 9 10 11 0:002> k *** Stack trace for last set context - .thread/.cxr resets it ChildEBP RetAddr 0095f07c 6ba8dc5f msvcr120!abort+0x38 [f:\dd\vctools\crt\crtw32\misc\abort.c @ 90] 0095f0ac 6b99f353 msvcr120!terminate+0x33 [f:\dd\vctools\crt\crtw32\eh\hooks.cpp @ 96] 0095f8fc 6ba1c01d msvcp120!_Call_func+0x2e [f:\dd\vctools\crt\crtw32\stdcpp\thr\threadcall.cpp @ 35] 0095f934 6ba1c001 msvcr120!_callthreadstartex+0x1b [f:\dd\vctools\crt\crtw32\startup\threadex.c @ 376] 0095f940 7685ee6c msvcr120!_threadstartex+0x7c [f:\dd\vctools\crt\crtw32\startup\threadex.c @ 354] 0095f94c 77053ab3 kernel32!BaseThreadInitThunk+0xe 0095f98c 77053a86 ntdll!__RtlUserThreadStart+0x70 0095f9a4 00000000 ntdll!_RtlUserThreadStart+0x1b
可以看到，显示出来的调用栈几乎没有用处，只能看出子线程在开始之后就调用了terminate函数来终止程序，完全看不出来是什么原因导致的。
在调试的时候，如果遇到难以逾越的问题，不妨大胆地进行推测，并根据这些推测进行尝试。推测不一定是正确的，但是在尝试的过程中很可能会发现新的解法。在当前这个例子中，即使不了解std::thread子线程的具体实现，也不难根据上面的调用栈推测出来。下面是一种可能的实现方式：
1 2 3 4 5 6 7 8 9 void _Call_func() { try { ThreadEntry (); } catch (...) { terminate (); } }
_Call_func函数用来调用在std::thread的构造函数中传进来的入口函数，在本例中即是ThreadEntry。该入口函数通过一对try/catch包裹起来，凡是在它里面抛出来的未处理异常都会被捕获，继而调用terminate函数来终止程序。由于terminate是在_Call_func函数中调用的，所以从调用栈上来看，terminate的上一个栈帧必然是_Call_func，ThreadEntry内部的所有栈帧都被跳过了。
根据以上的推测可知，异常发生时的调用栈还原不出来，只是因为它的栈帧被跳过了而已，假如这些栈帧还保留着，那肯定还是能还原出来的。继续观察上述的调用栈，发现_Call_func和terminate的栈帧之间尚有大约2KB（根据ChildEBP计算得来，0095f8fc - 0095f0ac）的内容，因此可以有八九分把握确定被跳过的栈帧就在这里面。
接下来要通过手工方式寻找那些被跳过的栈帧。从terminate栈帧的ChildEBP开始，使用dps命令逐步向上寻找。如下所示：
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 0:002> dps 0095f0ac l32 0095f0ac 0095f8fc 0095f0b0 6b99f353 msvcp120!_Call_func+0x2e [f:\dd\vctools\crt\crtw32\stdcpp\thr\threadcall.cpp @ 35] 0095f0b4 6ba097f2 msvcr120!_NLG_Return [f:\dd\vctools\crt\crtw32\eh\i386\lowhelpr.asm @ 64] 0095f0b8 0095f8f0 0095f0bc 0095f37c 0095f0c0 0095f0d0 0095f0c4 0095f8f0 0095f0c8 00000000 0095f0cc 0095f8fc 0095f0d0 0095f0fc 0095f0d4 6ba09861 msvcr120!_CallCatchBlock2+0x4f [f:\dd\vctools\crt\crtw32\eh\i386\trnsctrl.cpp @ 502] 0095f0d8 6b99f34d msvcp120!_Call_func+0x28 [f:\dd\vctools\crt\crtw32\stdcpp\thr\threadcall.cpp @ 35] 0095f0dc 0095f8f0 0095f0e0 00000100 0095f0e4 0095f158 0095f0e8 6ba09ffc msvcr120!CatchGuardHandler [f:\dd\vctools\crt\crtw32\eh\i386\trnsctrl.cpp @ 535] 0095f0ec c29105eb 0095f0f0 6b9b4bc0 msvcp120!_CTA4?AVsystem_errorstd+0x7c 0095f0f4 0095f8f0 0095f0f8 00000001 0095f0fc 0095f168 0095f100 6ba0999c msvcr120!CallCatchBlock+0x87 [f:\dd\vctools\crt\crtw32\eh\frame.cpp @ 1400] 0095f104 0095f8f0 0095f108 6b9b4bc0 msvcp120!_CTA4?AVsystem_errorstd+0x7c 0095f10c 6b99f34d msvcp120!_Call_func+0x28 [f:\dd\vctools\crt\crtw32\stdcpp\thr\threadcall.cpp @ 35] 0095f110 00000000 0095f114 00000100 0095f118 c2910467 0095f11c 0095f8f0 0095f120 6b9b4bac msvcp120!_CTA4?AVsystem_errorstd+0x68 0095f124 0095f8f0 0095f128 0095f898 0095f12c 00000000 0095f130 00000000 0095f134 00000000 0095f138 00000000 0095f13c 0095f128 0095f140 0095f8dc 0095f144 6b9ff756 msvcr120!_getptd+0x6 [f:\dd\vctools\crt\crtw32\startup\tidtable.c @ 337] 0095f148 00000000 0095f14c 6b99f34d msvcp120!_Call_func+0x28 [f:\dd\vctools\crt\crtw32\stdcpp\thr\threadcall.cpp @ 35] 0095f150 0095f118 0095f154 c291048b 0095f158 0095f2a8 0095f15c 6ba0a0d5 msvcr120!_except_handler4 [f:\dd\vctools\crt\crtw32\misc\i386\chandler4gs.c @ 84] 0095f160 a9a46ccf 0095f164 00000001 0095f168 0095f1a4 0095f16c 6ba09a50 msvcr120!CatchIt+0x69 [f:\dd\vctools\crt\crtw32\eh\frame.cpp @ 1211] 0095f170 0095f37c
这个寻找过程需要耐心和运气，因为dps命令输出的结果非常多，而且有些并不是真正的栈帧。在不了解C++异常处理的情况下只能逐个排查，排查的方法是，使用k命令从该栈帧开始回溯调用栈，看看最终能不能到达KiUserExceptionDispatcher的栈帧。例如，可以从上面结果的最后一个栈帧CatchIt开始回溯。要注意，根据栈帧的结构，0095f16c存放的是返回地址，上一个0095f168存放的才是ebp，所以应使用0095f168来回溯。结果如下所示：
1 2 3 4 5 6 7 8 9 10 11 12 0:002> k = 0095f168 ChildEBP RetAddr 0095f07c 6ba8dc5f msvcr120!abort+0x38 [f:\dd\vctools\crt\crtw32\misc\abort.c @ 90] 0095f168 6ba09a50 msvcr120!terminate+0x33 [f:\dd\vctools\crt\crtw32\eh\hooks.cpp @ 96] 0095f1a4 6ba095ab msvcr120!CatchIt+0x69 [f:\dd\vctools\crt\crtw32\eh\frame.cpp @ 1211] 0095f220 6ba09638 msvcr120!FindHandler+0x27b [f:\dd\vctools\crt\crtw32\eh\frame.cpp @ 689] 0095f254 6ba096ba msvcr120!__InternalCxxFrameHandler+0xd6 [f:\dd\vctools\crt\crtw32\eh\frame.cpp @ 439] 0095f290 770372b9 msvcr120!__CxxFrameHandler3+0x26 [f:\dd\vctools\crt\crtw32\eh\i386\trnsctrl.cpp @ 301] 0095f2b4 7703728b ntdll!ExecuteHandler2+0x26 0095f2d8 7700f9d7 ntdll!ExecuteHandler+0x24 0095f364 77037117 ntdll!RtlDispatchException+0x127 0095f364 00000000 ntdll!KiUserExceptionDispatcher+0xf
这个调用栈最终到达了KiUserExceptionDispatcher，也就是我们要找的栈帧。为什么要找KiUserExceptionDispatcher的栈帧呢？这是因为在Windows下所有异常都是通过KiUserExceptionDispatcher这个函数抛出来的，这个函数具有两个类型分别为PEXCEPTION_RECORD和PCONTEXT的参数，分别指向异常信息以及异常发生时的线程环境信息。
既然找到了KiUserExceptionDispatcher的栈帧，那么可以换用kb命令，显示出它的参数列表：
1 2 3 4 0:002> kb = 0095f168 ChildEBP RetAddr Args to Child （略） 0095f364 00000000 0095f37c 0095f39c 0095f37c ntdll!KiUserExceptionDispatcher+0xf
可知PEXCEPTION_RECORD的值是0095f37c，PCONTEXT的值是0095f39c。
WinDbg提供了.exr命令来显示PEXCEPTION_RECORD的内容，如下所示：
1 2 3 4 5 6 7 8 9 10 11 12 13 0:002> .exr 0095f37c ExceptionAddress: 74c4812f (KERNELBASE!RaiseException+0x00000058) ExceptionCode: e06d7363 (C++ EH exception) ExceptionFlags: 00000001 NumberParameters: 3 Parameter[0]: 19930520 Parameter[1]: 0095f898 Parameter[2]: 6b9b5734 pExceptionObject: 0095f898 _s_ThrowInfo : 6b9b5734 Type : class std::out_of_range Type : class std::logic_error Type : class std::exception
可以看到这是一个C++异常，并且类型是std::out_of_range。
WinDbg亦提供了.cxr命令，可以切换到指定PCONTEXT的线程环境，如下所示：
1 2 3 4 5 6 0:002> .cxr 0095f39c eax=0095f7f8 ebx=00431ee8 ecx=00000003 edx=00000000 esi=6b9b5734 edi=0095f898 eip=74c4812f esp=0095f7f8 ebp=0095f848 iopl=0 nv up ei pl nz ac po nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000212 KERNELBASE!RaiseException+0x58: 74c4812f c9 leave
至此，异常发生时的各种寄存器信息一览无余。此时使用k命令即可得到异常发生时的调用栈：
1 2 3 4 5 6 7 8 9 10 11 12 13 14 0:002> k *** Stack trace for last set context - .thread/.cxr resets it ChildEBP RetAddr 0095f848 6ba09339 KERNELBASE!RaiseException+0x58 0095f888 6b983a3a msvcr120!_CxxThrowException+0x5b [f:\dd\vctools\crt\crtw32\eh\throw.cpp @ 152] 0095f8a4 00c2104c msvcp120!std::_Xout_of_range+0x2e [f:\dd\vctools\crt\crtw32\stdcpp\xthrow.cpp @ 24] 0095f8cc 00c211ac ConsoleApplication!ThreadEntry+0x4c [c:\users\zplutor\documents\projects\tests\consoleapplication\main.cpp @ 9] 0095f8d4 6b99f33c ConsoleApplication!std::_LaunchPad<std::_Bind<1,void,void (__cdecl*const)(void)> >::_Go+0xc [c:\program files\microsoft visual studio 12.0\vc\include\thr\xthread @ 187] 0095f8fc 6ba1c01d msvcp120!_Call_func+0x17 [f:\dd\vctools\crt\crtw32\stdcpp\thr\threadcall.cpp @ 28] 0095f934 6ba1c001 msvcr120!_callthreadstartex+0x1b [f:\dd\vctools\crt\crtw32\startup\threadex.c @ 376] 0095f940 7685ee6c msvcr120!_threadstartex+0x7c [f:\dd\vctools\crt\crtw32\startup\threadex.c @ 354] 0095f94c 77053ab3 kernel32!BaseThreadInitThunk+0xe 0095f98c 77053a86 ntdll!__RtlUserThreadStart+0x70 0095f9a4 00000000 ntdll!_RtlUserThreadStart+0x1b
本文开头提到的现象并不是std::thread特有的。事实上，如果在捕获了一个异常之后的处理过程中又抛出了一个新的异常，那么旧异常的调用栈会被新异常的调用栈覆盖。在本文的例子中，_Call_func捕获了第一个异常之后，调用了terminate函数，terminate继而又调用了abort函数来抛出新的异常。使用本文提到的方法，就可以应对这种情况，还原出旧异常的调用栈。
原文来自：如何调试在std::thread子线程中抛出的C++异常 | Zplutor's
Comments
Post a Comment