我们有一个在MIP核上运行的Linux内核的embedded式版本。 我们编写的程序运行一个特定的testing套件。 在其中一个压力testing（运行约12小时），我们得到一个seg故障。 这又会产生一个核心转储。
不幸的是，核心转储并不是很有用。 崩溃是在一些dynamic链接的系统库（可能是pthread或glibc）。 核心转储中的回溯没有帮助，因为它只显示崩溃点，没有其他调用者（我们的用户空间应用程序是用-g -O0构build的，但仍然没有后台跟踪信息）：
Cannot access memory at address 0x2aab1004 (gdb) bt #0 0x2ab05d18 in ?? () warning: GDB can't find the start of the function at 0x2ab05d18. GDB is unable to find the start of the function at 0x2ab05d18 and thus can't determine the size of that function's stack frame. This means that GDB may be unable to access that stack frame,or the frames below it. This problem is most likely caused by an invalid program counter or stack pointer. However,if you think GDB should simply search farther back from 0x2ab05d18 for code which looks like the beginning of a function,you can increase the range of the search using the `set heuristic-fence-post' command.
另一个不幸的是，我们不能运行gdb / gdbserver。 gdb / gdbserver在__nptl_create_event上不断出现。 看到testing创造了线程，定时器和破坏，然后每5秒钟几乎不可能持续很长时间。
编辑：另一个说明，backtrace和backtrace_symbols不支持我们的工具链。
C：接收信号时，停止执行并跳转到程序中的特定点
Windows相当于SIGPROF
Linux阻塞信号到Python初始化
正确使用易失性sig_atomic_t
去应用程序无法捕捉信号
因此：
是否有陷阱seg故障和生成更多的回溯数据，堆栈指针，调用堆栈等方法？
谢谢。
程序终止于接收信号SIG34，实时事件34
从信号处理程序唤醒线程
如何拦截linux信号？ （在C）
实时信号的意义？
我如何触发默认的信号处理行为？
如果一切都失败，使用调试器运行命令！
只需将“gdb”以正常启动命令的形式输入，然后输入“c”即可启动进程运行。 当任务段错误时，它将返回交互式gdb提示符而不是核心转储。 你应该能够得到更有意义的堆栈跟踪等
如果可用，另一个选择是使用“truss”。 这会告诉你在异常结束时正在使用哪些系统调用。
GDB在0x2ab05d18找不到函数的开始
发生事故时的地址是什么？
info shared ，并找出是否有包含该地址的图书馆。
你的麻烦最可能的原因是：你上传到你的目标之前运行strip libpthread.so.0吗？ 不要这样做：GDB要求libpthread.so.0 不要被剥离。 如果您的工具链包含带有调试符号的libpthread.so.0 （因此对于目标而言太大），请对其执行strip -g ，而不是完整的strip 。
更新：
产生的info shared无法访问地址0x2ab05d18处的内存
这意味着GDB无法访问共享库列表（这将解释缺少的堆栈跟踪）。 最常见的原因是：实际生成core的二进制文件与您提供给GDB的二进制文件不匹配。 一个不太常见的原因：你的核心转储被截断（可能是由于ulimit -c被设置得太低）。
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 [email protected] 举报，一经查实，本站将立刻删除。
