_dl_sysinfo_int80 () 处的核心转储
我创建了一个连接到侦听服务器的 TCP 客户端。 我们还实现了 TCP keep-alive。 有时客户端崩溃并且核心被转储。 下面是核心转储跟踪。
该问题出现在 Linux 内核版本 Update 4、内核 2.6.9-42.0.10 中。
我们有两个核心转储。
(gdb) where
#0 0x005e77a2 in _dl_sysinfo_int80 () from /ddisk/d303/dumps/mhx239131/ld-
linux.so.2
#1 0x006c8bd1 in connect () from /ddisk/d303/dumps/mhx239131/libc.so.6
#2 0x08057863 in connect_to_host ()
#3 0x08052f38 in open_ldap_connection ()
#4 0x0805690a in new_connection ()
#5 0x08052cc9 in ldap_open ()
#6 0x080522cf in checkHosts ()
#7 0x08049b36 in pollLDEs ()
#8 0x0804d1cd in doOnChange ()
#9 0x0804a642 in main ()
(gdb) where
#0 0x005e77a2 in _dl_sysinfo_int80 () from /ddisk/d303/dumps/mhx239131/ld-
linux.so.2
#1 0x0068ab60 in __nanosleep_nocancel (
from /ddisk/d303/dumps/mhx239131/libc.so.6
#2 0x080520a2 in Sleep ()
#3 0x08049ac1 in pollLDEs ()
#4 0x0804d1cd in doOnChange ()
#5 0x0804a642 in main ()
我们尝试在我们的环境中重现该问题，但未能成功。
什么会导致core文件？
我怎样才能避免这种情况呢？
I have created a TCP client that connects to a listening server.
We implemented TCP keep alive also.
Sometimes the client crashes and core is dumped.
Below are the core dump traces.
The problem is in Linux kernel version Update 4, kernel 2.6.9-42.0.10.
We had two core dumps.
(gdb) where
#0 0x005e77a2 in _dl_sysinfo_int80 () from /ddisk/d303/dumps/mhx239131/ld-
linux.so.2
#1 0x006c8bd1 in connect () from /ddisk/d303/dumps/mhx239131/libc.so.6
#2 0x08057863 in connect_to_host ()
#3 0x08052f38 in open_ldap_connection ()
#4 0x0805690a in new_connection ()
#5 0x08052cc9 in ldap_open ()
#6 0x080522cf in checkHosts ()
#7 0x08049b36 in pollLDEs ()
#8 0x0804d1cd in doOnChange ()
#9 0x0804a642 in main ()
(gdb) where
#0 0x005e77a2 in _dl_sysinfo_int80 () from /ddisk/d303/dumps/mhx239131/ld-
linux.so.2
#1 0x0068ab60 in __nanosleep_nocancel (
from /ddisk/d303/dumps/mhx239131/libc.so.6
#2 0x080520a2 in Sleep ()
#3 0x08049ac1 in pollLDEs ()
#4 0x0804d1cd in doOnChange ()
#5 0x0804a642 in main ()
We have tried to reproduce the problem in our environment, but we could not.
What would cause the core file?
How can I avoid such a situation?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
_dl_sysinfo_int80只是一个对内核进行系统调用的函数。 因此，核心转储发生在系统调用上（可能是第一个示例中的connect使用的系统调用和第二个示例中的nanosleep使用的系统调用），可能是因为您传递了无效的指针。无效的指针可能是因为调用这些函数的代码被破坏或者因为程序中的其他地方被破坏并破坏了程序的内存。
查看两个示例的核心转储中上面的两个帧（帧
#2），并检查正在传递的参数。 不幸的是，您似乎没有使用调试信息进行编译，因此更难看到它们。此外，我建议尝试 valgrind 并看看它是否找到了一些东西。
_dl_sysinfo_int80is just a function which does a system call into the kernel. So the core dump is happening on a system call (probably the one used byconnectin the first example andnanosleepin the second example), probably because you are passing invalid pointers.The invalid pointers could be because the code which calls these functions being broken or because somewhere else in the program is broken and corrupting the program's memory.
Take a look at two frames above (frame
#2) in the core dump for both examples and check the parameters being passed. Unfortunately, it seems you did not compile with debug information, making it harder to see them.Additionally, I would suggest trying
valgrindand seeing if it finds something.您的程序几乎肯定没有在上述任一位置进行核心转储。
最有可能的是，您的进程中有多个线程（以及其他一些线程导致了核心转储），或者外部原因导致您的进程终止（例如
'kill -SIGABRT' ） 。如果您确实有多个线程，GDB
'infothreads'和'thread apply allwhere'可能会提供进一步的线索。Your program almost cetainly did not coredump in either of the above places.
Most likely, you either have multiple threads in your process (and some other thread caused the core dump), or something external caused your process to die (such as
'kill -SIGABRT <pid>').If you do have multiple threads, GDB
'info threads'and'thread apply all where'are likely to provide further clues.