回溯指向 fopen 崩溃答案

【问题标题】：Backtrace points to fopen crash回溯指向 fopen 崩溃
【发布时间】：2013-05-23 21:49:20
【问题描述】：

以下是我从最近的一次崩溃中得到的回溯。它指向 fopen 调用。不知道这里发生了什么。设备上有足够的空间。 & 即使文件不是他们的，它也应该返回 NULL。

崩溃没有意义。这是BT

(gdb) bt 
#0  0xb788f50e in __open_nocancel () from /tmp/user_20130523143934/x86/lib/tls/libc.so.6
#1  0xb78453e7 in *__GI__IO_file_open (fp=0x814b0e4, filename=0xb78fc1f5 "/init_log.cfg", posix_mode=-2, prot=438, read_write=8, is32not64=0) at fileops.c:233
#2  0xb784555c in _IO_new_file_fopen (fp=0x814b0e4, filename=0xb78fc1f5 "/init_log.cfg", mode=0x1b6 <Address 0x1b6 out of bounds>, is32not64=1) at fileops.c:332
#3  0xb783d519 in __fopen_internal (filename=0xb78fc1f5 "/init_log.cfg", mode=0xb78fc1f3 "r", is32=1) at iofopen.c:93
#4  0xb783d55f in _IO_new_fopen (filename=0xb78fc1f5 "/init_log.cfg", mode=0xb78fc1f3 "r") at iofopen.c:107
#5  0xb78fbe00 in init_setup (app_uuid=1009, mod_uuid=0, hdl=0xfffffffe) at ../init_setup_api.c:1013
#6  0x0805f431 in main (argc=1, argv=0xbffffa64) at .. vpg_agent.c:307


(gdb) frame 5
#5  0xb78fbe00 in init_setup (app_uuid=1009, mod_uuid=0, hdl=0xfffffffe) at ../init_setup_api.c:1013
1013        if ((fp = fopen(MY_FILE, "r")) == NULL) {
(gdb) l

感谢您的帮助。

PS：还有一件事，它是一个远程映射的文件系统。才知道的。那可能是有贡献的。

【问题讨论】：

很可能是内存损坏（可能就在fopen 之前，或者如果它是多线程应用程序，甚至同时发生）。或者你的程序可能没有虚拟内存。
另一个进程同时崩溃了，也指向了fopen
它是一个静态宏，指向一个文件位置。不应该是问题 rt，如果不是，它应该返回 NULL，而不是崩溃
gdb 告诉您正在使用不在系统常用路径（/tmp/user_20130523...）中的libc。也许问题就在那里，您使用的是非标准的 libc（可能是跟踪文件或类似的东西）并且它崩溃了？
是的，这是非标准的 libc，但它已经存在多年了。我们只有实际函数调用的包装器。这些包装器不会崩溃

标签： c linux gdb

【解决方案1】：

__open_nocancel 通常是系统调用的一个小包装。

这是我系统上的样子：

(gdb) disas __open_nocancel
Dump of assembler code for function __open_nocancel:
   0x000ddf5a <+0>:     push   %ebx
   0x000ddf5b <+1>:     mov    0x10(%esp),%edx
   0x000ddf5f <+5>:     mov    0xc(%esp),%ecx
   0x000ddf63 <+9>:     mov    0x8(%esp),%ebx
   0x000ddf67 <+13>:    mov    $0x5,%eax
   0x000ddf6c <+18>:    call   *%gs:0x10
   0x000ddf73 <+25>:    pop    %ebx
   0x000ddf74 <+26>:    cmp    $0xfffff001,%eax
   0x000ddf79 <+31>:    jae    0xddfad <open+93>
   0x000ddf7b <+33>:    ret    
End of assembler dump.

很可能您的 PC 0xb788f50e 对应于我在 0x000ddf73 的指令，即紧跟在系统调用本身之后的指令。

如果是这样，有几种可能的解释：

您正在查看错误的线程，而不是实际崩溃的线程。
(gdb) info thread 显示什么？
您的内核对系统上发生的某些事情不满意，并且正在终止左右进程。检查/var/log/messages 寻找线索。

另一方面，如果您在0xb788f50e 的指令对应于我在0x000ddf6c 的指令（即call 本身），那么也许您将ulimit -s 设置得太低了？

最后，如果您启用了 SELinux，它可能会终止您，因为您违反了它的政策。检查适当的 selinux.log。

【讨论】：