如何从陷阱获取核心转储：program[pid] 一般保护事件
我正在尝试对 Linux 上本地编译的守护程序进行故障排除，该程序因信号 11 而崩溃，我需要追溯堆栈和变量值来修复该错误。
然而，由于某种原因，Linux 内核不保存核心转储，而只是记录以下内容（暂时不给出程序名称）：
Apr 8 15:22:54 machinename kernel: [ 5032.337089] traps: program[4121] general protection ip:7ff47cbf9614 sp:7ff45f68abb8 error:0
Apr 8 15:22:54 machinename kernel: [ 5032.337110] in libc-2.19.so[7ff47cb7d000+1a1000]
我已经尝试确保 core(5) 满意，但无济于事。
有没有办法让 Linux 内核报告或记录它不生成核心转储的原因？
还有其他方法可以解决这种情况吗？
请注意，这与该主题的其他问题的不同之处在于： 1. 不特定于指定的程序或库及其特性。 2. 寻找对遇到这种有点令人困惑的内核行为的其他开发人员通用的答案。
I am trying to troubleshoot a locally compiled daemon program on Linux, the program crashes with signal 11, and I need to trace back the stack and values of variables to fix the bug.
However for some reason the Linux kernel does not save a core dump, but simply logs the following (not giving a away the program name for now):
Apr 8 15:22:54 machinename kernel: [ 5032.337089] traps: program[4121] general protection ip:7ff47cbf9614 sp:7ff45f68abb8 error:0
Apr 8 15:22:54 machinename kernel: [ 5032.337110] in libc-2.19.so[7ff47cb7d000+1a1000]
I have already tried to ensure the criteria in core(5) are satisfied, but to no avail.
Is there a way to make the Linux kernel report or log why it is not producing a core dump?
Is there any other way to troubleshoot that situation?
Note that this differs from other questions on the topic by: 1. Not being specific to a named program or library and its idiosynchasies. 2. Looking for answers that will be of general use to other developers hit with this somewhat confusing kernel behaviour.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我最终通过构建具有额外代码的自定义内核来修复了这一点，以记录编写或不编写核心转储的确切原因（这确实应该是默认行为，但不是）。事实证明，尽管守护程序不是SUID二进制文件，但仍应用了一个已记录的标准（SUID_DUMPABLE），它在守护程序时才掉落了根，从安全角度来看，这是相反的。
因此，我将suid_dumpable更改为1，获得了一个核心转储文件，并使用源代码将其复制到计算机上，然后努力使GDB加载符号（对此也有很多不清楚的文档）。但是最终，我足够近，以怀疑原因并在守护程序代码中实施解决方法。
因此，对他人的课程：/proc/sys/fs/suid_dumpable应用于在无特点的用户ID下运行的二进制文件，尽管设置了一个设置，以防止SUID二进制文件将用户可读的核心文件倾倒使用，并具有在特权帐户中获得的特权信息。
I finally fixed this by building a custom kernel with extra code to log the exact reason for writing or not writing a core dump (this really should be default behavior, but isn't). Turns out that one of the documented criteria (suid_dumpable) was applied despite the daemon not being an suid binary, it just dropped root when daemonizing, which is kind of the opposite from a security perspective.
So I changed suid_dumpable to 1, got a core dump file and copied it to the machine with the source code, then struggled with getting gdb to load the symbols (lots of unclear documentation on that too). But eventually, I got close enough to suspect a cause and implement a workaround in the daemon code.
So lesson for others: /proc/sys/fs/suid_dumpable is applied to binaries that drop root to run under an unprivileged user id, despite being a setting to protect against suid binaries dumping user readable core files with privileged information obtained under a privileged account.