调试用C编写的linux守护进程

有时，我用C编写的守护进程会收到以下错误消息：

[Fri Dec 30 07:58:54 2016] listend[13944]: segfault at 0 ip b7601e22 sp bf901d00 error 4 in libc-2.19.so[b7575000+1a7000]

[Fri Dec 30 07:58:54 2016] listend[13948]: segfault at 0 ip b7601e22 sp bf901d00 error 4 in libc-2.19.so[b7575000+1a7000]

[Fri Dec 30 07:58:54 2016] listend[13949]: segfault at 0 ip b7601e22 sp bf901d00 error 4 in libc-2.19.so[b7575000+1a7000]

[Fri Dec 30 07:58:54 2016] listend[13950]: segfault at 0 ip b7601e22 sp bf901d00 error 4 in libc-2.19.so[b7575000+1a7000]

[Fri Dec 30 07:58:54 2016] listend[13951]: segfault at 0 ip b7601e22 sp bf901d00 error 4 in libc-2.19.so[b7575000+1a7000]

[Fri Dec 30 07:58:54 2016] listend[13952]: segfault at 0 ip b7601e22 sp bf901d00 error 4 in libc-2.19.so[b7575000+1a7000]

[Fri Dec 30 07:58:54 2016] listend[13953]: segfault at 0 ip b7601e22 sp bf901d00 error 4 in libc-2.19.so[b7575000+1a7000]

[Fri Dec 30 07:58:54 2016] listend[13954]: segfault at 0 ip b7601e22 sp bf901d00 error 4 in libc-2.19.so[b7575000+1a7000]

[Fri Dec 30 07:58:54 2016] listend[13955]: segfault at 0 ip b7601e22 sp bf901d00 error 4 in libc-2.19.so[b7575000+1a7000]

我的问题是如何检查libc-2.19中的地址，以便在发生错误时查看调用了哪个函数？我试着使用gdb

但我得到：

$ gdb code/listen/i686-Linux/listend 
.
.
(gdb) info addr 0xb7575000
No symbol "0xb7575000" in current context.
(gdb) info addr 0xb771c000
No symbol "0xb771c000" in current context.

---

根据您提供的数据，这里几乎无法对您的问题进行诊断。我可以推断的是，地址为0，指向代码中的

NULL

取消引用（您将

NULL

作为字符串地址的指针传递，或者类似的东西，这使得

printf（）

调用失败——或者类似的内容）。地址

0x1a7000

在libc中是引发异常的地方。您可以通过对libc.so.xx.xx.xx执行

nm（1）

来猜测函数名。转储内核（通过在执行守护程序之前设置ulimit-c unlimited）将允许使用后期调试程序。或者，守护进程的源代码也会有所帮助。很抱歉，您的问题远未完成，无法提供帮助。有关更多信息，请参阅。

在下运行守护程序。这个bug几乎肯定不在libc中；valgrind将揭示代码中触发第一次无效内存访问的点。这可能不是bug的根本原因，但它通常比现在更接近于根本原因。对，我想如果我能在libc中找到地址指向的函数，我可以将其追溯到我的代码中。我100%知道我的代码有bug，而不是libc；-）它还有助于编译代码，而无需优化和调试符号：

gcc-O0-g…

。这将提高gdb和valgrind的输出。是的，gcc-Wall-ggdb是我构建的工具。你能用gdb连接到守护进程并等待它崩溃吗？或者您可以将崩溃转储加载到gdb中吗？看看调用堆栈？这就是我想要的答案：通过对libc.so.xx.xx.xx执行nm（1），您可能可以猜出函数名。谢谢如果这是您正在寻找的答案，请将其标记为！：））您将通过验尸后的核心映像和gdb调试器获得实际答案。它会间歇性地抛出此错误，我已经监视了数天，有时甚至数周，试图捕获它。只需准备环境，使进程转储核心文件即可。您将在最后一个核心文件中获得最后一个失败，您不需要更多的时间来调试失败的位置，它可能总是相同的。执行没有失败也不会转储内核。我之前设置了ulimit-c unlimited，但是我还没有看到内核文件。