setjmp/信号崩溃异常处理答案

【问题标题】：setjmp/signal crash exception handlingsetjmp/信号崩溃异常处理
【发布时间】：2009-03-24 07:47:42
【问题描述】：

我正在尝试为 C OSX Carbon 多线程 应用程序安装“崩溃处理程序”。在 Windows 上，我可以轻松使用简单高效的__try{} __except{} SEH of Windows，效果很好。（请注意，这些与 C++ 异常无关，它们是较低级别的 C 构造！）

这与question I asked on SO previously非常相关：还有older SO question。

答案似乎是在每个代码区域之前使用 setjmp()，然后在发生崩溃时使用信号处理程序 longjmp() 返回。

但是这个实现是不平凡的..因为多线程！ Windows 中的 __try{} __except{} 习惯用法是线程安全的，并且可以正常工作。但显然 setjmp 不是线程安全的。

那么实现会是什么样子？我一直在想我将不得不实现一些线程本地存储。开始时我初始化 setjmp，将环境状态存储到线程本地缓冲区中，然后信号处理程序必须通过查看线程本地区域再次找到环境数据。但是，Google 和 SO 都没有显示任何证据表明这是正确的策略，特别是因为 setjmp() 被记录为线程不安全。线程本地存储不是需要每个线程都注册自己并分配内存（以保存该环境数据），并在线程销毁时释放它吗？

我希望我可以制作一个宏来包装所有这些，所以在 OSX 上，我的 __try __except 代码可以正常工作。

那么，如何使用信号和 setjmp 制作 OSX 多线程安全的崩溃恢复处理程序？

【问题讨论】：

标签： c multithreading macos exception-handling crash

【解决方案1】：

ReactOS 有一个名为PSEH 的 SEH 克隆。 ROS Newsletter #49 有一个简短的提及，您可以看到它是如何在 /include/crt/excpt.h、/include/reactos/lib/pseh/pseh2.h 等中实现的。使用宏和（当前仅限 x86）程序集看起来有点凌乱，但它可以工作.

话虽如此，信号+线程交互在 UNIX 上是出了名的丑陋，所以如果您想要 SEH 的目的是处理信号...我建议您找到一个替代解决方案。

【讨论】：

【解决方案2】：

我使用setjmp/longjmp 使用类似的异常处理，并且我有线程本地存储。对于每个新线程，我都会调用该线程的 malloc 本地 jmpbuf 的初始化函数。

注意！我从未在多线程环境中正确测试过它！

【讨论】：