在Linux中考虑这个问题.使用GCC编译器.
如果SIGSEGV(我的意思是通常导致SIGSEGV的违规)发生在信号处理程序中,其目的是捕获SIGSEGV,那么可以预期什么行为?帮助讨论的代码示例:
/* In main or whatever */{ struct sigaction sa = {}; /* initialised to all zero (I Vote for GCC style breach of standard here) */ sa.sa_handler = disasterSignals; sa.sa_flags = SA_resetHAND | SA_NODEFER; /* To have or have not */ sigaction(SIGSEGV,&sa,NulL);}static voID disasterSignals(int signal){ /* We cannot save the situation,the purpose of catching the signal is only to do something cLever to aID deBUGging before we go. */ /* Q: What if we segfault in here?? */ abort(); /* This should give us the expected core dump (if we survive to this point) */}
想象一下,在“Q”点,有一个违规的机器指令.
1)没有SA_resetHAND | SA_NODEFER:这似乎将系统置于逻辑陷阱中:在“Q”处,应生成SIGSEGV.但SIGSEGV在信号处理程序中被阻止(默认的sigaction行为).如何继续执行?会冻结吗?它是否会超越违规指令(我猜不是)?
2)使用SA_resetHAND | SA_NODEFER:我想在这种情况下,当重复SIGSEGV时,程序将以“正常”方式崩溃.
3)只有SA_NODEFER:我想在这种情况下,递归调用信号处理程序;如果SIGSEGV总是重复,我们会冻结,直到堆栈溢出,然后是什么.
最佳答案默认情况下,在处理信号时,它会被屏蔽,因此无法以递归方式触发.如果程序执行触发了屏蔽信号(无效的内存访问,段错误,除以0等),则行为未定义:If SIGBUS,SIGFPE,SIGILL,or SIGSEGV are generated while they are
blocked,the result is undefined,unless the signal was generated by
kill(2),sigqueue(3),or raise(3).
在我的系统上,它会导致进程崩溃.
对于SA_NODEFER,没有屏蔽,因此可以递归处理信号,直到堆栈溢出.添加SA_resetHAND将恢复默认 *** 作(SIGSEGV崩溃).
我将您的示例改编为简单的测试程序,因此您可以验证此行为:
#include
总结 以上是内存溢出为你收集整理的如果我捕获SIGSEGV并且信号处理程序导致另一个SIGSEGV会发生什么?全部内容,希望文章能够帮你解决如果我捕获SIGSEGV并且信号处理程序导致另一个SIGSEGV会发生什么?所遇到的程序开发问题。
如果觉得内存溢出网站内容还不错,欢迎将内存溢出网站推荐给程序员好友。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)