e.d*_*dan 2 c linux stack-trace
我已阅读(参见此处)在Linux下的故障信号处理程序(例如处理时)使用backtrace()打印堆栈跟踪的"常见做法" SIGSEGV是:
1 从未记录的结构中获取指令指针(EIP或RIP)sigcontext.
2用指令指针替换堆栈轨迹中的第2帧,因为第一帧是信号处理程序,第2帧应该libc在sigaction代码中,它覆盖了发生故障的原始帧.
3从新更换的第2帧开始打印回溯.
在我的测试中(在x86_642.6内核上),实际上发生故障的原始帧存在于backtrace()第3帧中给出的堆栈跟踪中 - 第一个是信号处理程序,第二个是libc信号处理代码.
内核信号处理的这种变化是否记录在某个地方,您可以参考我？
在我看来,结果是你可以避免从指令指针替换任何帧,并从第backtrace()3帧开始打印堆栈跟踪,但我想确认这是已知的行为和正确的方法.
这是一个有趣的尝试,但它不是真正的便携式,可能永远不会100%可靠.所以,按照你说的方式实现它,如果它适用于你的平台,并包含一些小的单元测试,以便你立即知道你将来使用的某个系统是否工作方式不同.毕竟,当调用此代码时,您已经搞砸了,所以尽可能做到最好并继续前进.
可以同时使用或代替您的方案使用的完全不同的替代方法是编写一个脚本,以便在程序转储核心时由Linux调用.然后,此脚本可以在核心文件上以批处理模式运行gdb以获取回溯并向您发送电子邮件或其他任何内容.