c++ - CRT 语言环境临界区死锁

Question

讨论应用程序错误:

很少有大多数应用程序线程卡在相同重复的死锁上。在 Windows XP 和更高版本上，死锁大约每月重现一次。

我们大型项目的基本要素:

当错误在客户机器上重现时，项目构建为发布目标。

使用/EHa 编译的应用程序因此捕获带有省略号 (...) 的 block 有时可能会隐藏访问冲突和其他系统异常。(请不要用省略号讨论 catch block 的好坏)。

项目由纯 CLR 和混合 CLR 程序集(C++；C#；C++\CLI)组成。

MSVS 2013

大多数应用程序线程使用线程本地 C 语言环境模式。

WinDbg dump info, most essential

WinDbg dump info, full stack traces

Full dump (70Mb)

大多数线程等待 CRT 语言环境临界区(CRT 源上的“_mlock(_SETLOCALE_LOCK)”代码)，例如WinDbg_ID=44 的线程。

等待加载程序临界区的其他线程，例如WinDbg_ID=23 的线程。

可能有 23 个线程在 CRT 源内部进入 CRT 区域设置临界区并且没有离开它。

44 线程在 _CRTDLL_INIT/dllmain 之前进入加载程序临界区，并在执行 DLL_THREAD_ATTACH 时等待 _CRTDLL_INIT/dllmain 处的 crt-locale 临界区。

dllmain 是默认生成的。

必须保留语言环境临界区，因为 _munlock(_SETLOCALE_LOCK) 应该位于 CRT 源的 __finally block 中。

可能在进入 CRT 语言环境临界区后以及 _munlock 未离开 CRT 语言环境临界区时发生一些系统异常。

有点不寻常:进程中有 3 个模块:

• msvcr80.dll - 由 sqlncli10.dll 加载
• msvcr120.dll
• msvcr120_clr0400.dll

问题:

有没有人有一些想法或解释？

是否可以从单线程调用来自不同 CRT 版本的 CRT 区域设置函数？由于 CRT 差异，这可能会破坏线程本地 CRT 语言环境数据内存。进入CRT locale临界区后出现了一些系统异常。是真的吗？

是否可以跳过 __finally block ？跳过场景？

Answer 1

可能我们找到了答案并将在实践中对此进行测试。

我们对 vector 异常处理程序中的每个非 C++ 异常运行回溯记录器，并在它发生时捕获堆栈跟踪。锁定区域设置 CS 后访问冲突。

我们在我们的项目中以多线程方式使用了第三方库 ZipArchive。在这个 CZipString::MakeLower\CZipString::MakeUpper 深处的库函数中，使局部静态变量 std::locale 并且这是多线程情况下 C++98/MsVs 2013 中的 UB。它很少只是破坏堆栈顶部并调用代码部分中的随机代码，而堆栈不会正确展开并且不会离开语言环境 CS。然后发生访问冲突，线程状态由/EHa 和 catch(...)“恢复”。在不正确的堆栈展开后，线程卡在另一个 CS。

谢谢大家。