gdb - 如何使用gdb和core-dump文件找到这个segmentation fault的原因？(GDB的局限性)

Question

我知道我可以使用核心转储文件找出程序哪里出错了。但是有一些BUG，就是用core文件调试也不知道为什么会出错。所以我想传达的是，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)

.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 和核心文件也无法调试的错误范围？仅回答一个问题的答案也将被接受。

谢谢!

---

我持有的重要假设:

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

Answer 1

the scope of the bugs that gdb and core files can help you to debug is limited.

正确:core dump 对几大类 bug 几乎没有帮助。最常见的(以我的经验)是:

1. 进程启动时发生的问题(例如您展示的示例)。

   GDB 需要与动态加载器合作，以告知 GDB 各种 ELF 镜像在进程空间中的哪些位置mmap。

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

2. 各种堆损坏错误。

   通常您可以判断出问题很可能是堆损坏(例如，malloc 或 free 中的任何崩溃通常是一个迹象)，但这告诉您很少关于问题的根本原因。

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

3. 各种堆栈溢出错误。

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

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

4. 各种“逻辑”错误。

   例如，假设您有一个树数据结构和一个访问其节点的递归过程。如果你的树不是一棵正确的树，并且其中有一个循环，你的访问过程将用完堆栈并崩溃。

   但是看着崩溃告诉你什么树不再是树而是变成了图形的地方。

5. 数据竞赛。

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

   当其他线程修改您下面的向量(或任何其他数据结构)时，通常会发生这种情况。

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