【问题标题】:Handling segfault signal SIGSEGV need to determine the cause of segfault using siginfo_t处理segfault信号SIGSEGV需要使用siginfo_t判断segfault的原因
【发布时间】:2010-12-20 13:58:47
【问题描述】:

我正在为 pthread 库制作一个包装器,它允许每个线程拥有自己的一组非共享内存。现在,如果任何线程尝试读取另一个线程数据,则设置 c 的方式,程序段错误。这很好,我可以用 sighandler 捕捉它并调用 pthread_exit() 并继续执行该程序。

但并非每个段错误都会是错误 rwe 的结果。我需要找到一种方法来使用 siginfo 类型来确定段错误是编程错误还是这个错误。有什么想法吗?

由于我使用 mmap 来管理内存页面,我认为在 siginfo 中使用 si_addr 会有所帮助。

【问题讨论】:

    标签: pthreads signals segmentation-fault


    【解决方案1】:

    听起来你真正追求的是线程本地存储,它已经解决了比这更便携的问题。 GCC 提供__thread,MSVC 提供__declspec(thread)boost::thread 根据平台/工具链等使用多种机制提供可移植的线程本地存储。

    如果你真的想走这条路,它可以工作,但这条路充满了危险。从 SIGSEGV 中恢复在技术上是未定义的行为,尽管它可以在相当多的平台上工作,但它既不健壮也不可移植。不过,您也需要非常小心您在信号处理程序中所做的事情——async-safe 函数的列表,即可以合法地从信号处理程序安全调用的函数的列表非常小。

    过去我已经成功使用过几次这个技巧,通常用于在用户空间中将“页面”标记为“脏”。我这样做的方法是设置一个哈希表,其中包含我感兴趣的所有内存“页面”的基地址。当您在处理程序中捕获 SIGSEGV 时,您可以使用简单的方法将地址映射回页面算术运算。如果哈希表可以在没有锁的情况下读取,那么您可以查找这是您关心的页面还是来自其他地方的段错误并决定如何采取行动。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 2011-08-08
      • 2011-08-14
      • 2019-03-17
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多