如何使用 gdb 和 core-dump 文件查找此分段错误的原因？（GDB 的限制）

Posted

技术标签:

【中文标题】如何使用 gdb 和 core-dump 文件查找此分段错误的原因？（GDB 的限制）【英文标题】：How to find the cause of this segmentation fault using gdb and core-dump file?(Limitation of GDB) 【发布时间】：2018-03-06 03:00:17 【问题描述】：

我知道我可以使用核心转储文件找出程序出错的地方。但是，有一些错误，即使你用核心文件调试它，你仍然不知道它为什么会出错。所以我想传达的是gdb和core文件可以帮助你调试的bug的范围是有限的。那有多大限制？

例如，我写如下代码：(libfoo.c)

#include <stdio.h>
#include <stdlib.h>
void foo(void);
int main()

    puts("This is a mis-compiled runnable shared library");
    return 0;

void foo()

    puts("This is the shared function");

以下是makefile：（Makefile）

.PHONY : all clean
all : libfoo.c
    gcc -g -Wall -shared -fPIC -Wl,-soname,$(basename $^).so.1 -o $(basename $^).so.1.0.0 $^; \
#the correct compiling command should be : 
#gcc -g -Wall -shared -fPIC -pie -Wl,--export-dynamic,-soname,$(basename $^).so.1 -o $(basename $^).so.1.0.0 $^; 
    sudo ldconfig $(CURDIR);                        #this will set up soname link     \ 
    ln -s $(basename $^).so.1.0.0 $(basename $^).so #this will set up linker name link;
clean : 
    -rm libfoo.s*; sudo ldconfig;#roll back

当我运行它./libfoo.so 时，我遇到了分段错误，这是因为我以错误的方式编译了可运行共享库。但我想确切地知道是什么导致了分段错误。所以我使用了gdb libfoo.so.1.0.0 corefile，然后是bt，得到了以下结果：

[xhan@localhost Desktop]$ gdb ./libfoo.so core.8326 
GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-100.el7
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /home/xiaohan/Desktop/libfoo.so.1.0.0...done.

warning: core file may not match specified executable file.
[New LWP 8326]
Core was generated by `./libfoo.so'.
Program terminated with signal 11, Segmentation fault.
#0  0x0000000000000001 in ?? ()
(gdb) bt
#0  0x0000000000000001 in ?? ()
#1  0x00007ffd29cd13b4 in ?? ()
#2  0x0000000000000000 in ?? ()
(gdb) quit

但我仍然不知道是什么导致了分段错误。调试核心文件不能给我任何线索，我的分段错误的原因是我使用了错误的编译命令。

谁能帮我调试一下？或者谁能​​告诉我即使使用 gdb 和核心文件也无法调试的错误范围？只回答一个问题的答案也将被接受。

谢谢！

我持有的重要假设：

    有些人可能会问我为什么要使共享库可运行。我这样做是因为我想编译一个类似于/lib64/ld-2.17.so 的共享库。 当然，您不能依赖 gdb 告诉您造成每个错误的原因。例如，如果你只是简单地chmod +x nonexecutable 并运行它，然后得到一个错误（通常这不会转储核心文件），并尝试使用 gdb 调试它，这有点“疯狂”。但是，一旦可以在运行时加载“可执行文件”并转储核心文件，您就可以使用 gdb 对其进行调试，此外，还可以找到有关程序出错原因的线索。但是，在我的问题./libfoo.so 中，我完全迷失了。

【问题讨论】：

【参考方案1】：

gdb 和 core 文件可以帮助你调试的 bug 的范围是有限的。

正确：有几大类错误，core dump 几乎没有帮助。最常见的（根据我的经验）是：

    进程启动时发生的问题（例如您展示的示例）。

    GDB 需要与动态加载器合作，告诉 GDB 各种 ELF 图像在进程空间中mmaped 的位置。

    当崩溃发生在动态加载器本身时，或者在动态加载器有机会告诉 GDB 事情在哪里之前，你最终会得到一个非常混乱的画面。

    各种堆损坏错误。

    通常您可以看出问题很可能是堆损坏（例如，malloc 或 free 内部的任何崩溃通常都是一个迹象），但这告诉您很少问题的根本原因。

    幸运的是，Valgrind 和 Address Sanitizer 等工具通常可以直接指出问题所在。

    各种堆栈溢出错误。

    GDB 使用当前堆栈的内容来告诉您如何到达您所在的函数 (backtrace)。

    但是如果你用垃圾覆盖堆栈内存，那么你如何到达你所在位置的记录就会丢失。如果你破坏了堆栈，然后使用“grbage”函数指针，那么你最终会得到一个核心转储，你无法知道你在哪里，或者你是如何到达那里的。

    各种“逻辑”错误。

    例如，假设您有一个树数据结构，以及一个访问其节点的递归过程。如果你的树不是一棵合适的树，并且其中有一个循环，那么你的访问过程将耗尽堆栈并崩溃。

    但是看崩溃告诉你什么关于树不再是树并变成图表的地方。

    数据竞赛。

    您可能正在迭代 std::vector 的元素并崩溃。检查向量表明它不再处于有效状态。

    这通常发生在其他线程从您下方修改向量（或任何其他数据结构）时。

    同样，崩溃堆栈跟踪很少告诉您错误的实际位置。

【讨论】：

谢谢！顺便问一下，是否有手册或指南可以让我了解使用 GDB 进行调试的局限性，并了解正在发明什么样的调试工具来克服 GDB 的缺点？或者这种知识只能从经验主义中获得？还是我必须彻底了解 GDB 的工作原理才能“批评”它？

以上是关于如何使用 gdb 和 core-dump 文件查找此分段错误的原因？（GDB 的限制）的主要内容，如果未能解决你的问题，请参考以下文章

Linux开启core-dump简单总结

Linux开启core-dump简单总结

编译库以便 GDB 自动查找源

如何使用 GDB 在内存空间中查找引用某个地址的所有指针？

在docker中使用gdb调试程序

linux core-dump生成