正常崩溃，但 GDB 不崩溃？

Question

我的程序在正常运行时因分段错误而崩溃。所以我用 gdb 运行它，但是当我这样做时它不会崩溃。有谁知道为什么会发生这种情况？我知道 Valgrind 的常见问题解答提到了这一点（在 valgrind 下没有崩溃），但我在谷歌中找不到与 gdb 相关的任何信息。如果有人能告诉我原因，或者在发生这种情况时推荐一些要寻找的东西，我将非常感激。

Answer 1

我以前也遇到过这种情况（你并不孤单），但我不记得我做了什么来解决问题（我认为这是双重免费的）。

我的建议是设置您的环境以创建核心转储，然后在程序崩溃后使用 GDB 调查核心转储。在 bash 中，这是通过 ulimit -c size 完成的，其中 size 可以是任何东西；我个人将 50000 用于 25MB 的最大大小；单位以 512 字节为增量。

您可以使用 GDB 通过 gdb program core 调查核心转储。

Answer 2

听起来像Heisenbug :-)

如果您使用的平台能够生成核心文件，则应该可以使用核心文件和 gdb 来查明程序崩溃的位置 - 可以在 here 找到简短说明。

尽管让它崩溃几次，当崩溃是由堆栈粉碎或变量覆盖引起的时，错误可能看起来“四处走动”。

Answer 3

嗯，我追踪到了一个 pthread_detach 调用。我在做 pthread_detach(&thethread)。我只是拿走了引用并将其更改为 pthread_detach(thethread) 并且它工作正常。我不是很肯定，但也许它是通过分离引用然后在超出范围时再次销毁它来实现双重释放？

Answer 4

尝试附加到gdb 中的正在运行的进程，继续，然后重现崩溃。也就是说，不要在gdb内启动程序；而是正常启动程序，然后attach <pid>。

有时在逐行单步执行时，不会出现导致程序崩溃的竞争条件，因为竞争风险已被消除或因步骤之间的“长时间”停顿而变得极不可能。

Answer 5

检查pthread_detach 调用的返回值。根据your answer，您可能将无效线程句柄传递给pthread_detach。

Answer 6

如果错误取决于时间，gdb 可能会阻止它重复。

Answer 7

我也遇到过这种情况。

我的解决方案：清理并重建所有内容。

并不是说这总能解决所有问题（在 OP 的情况下，问题是真的错误的），但是如果你在遇到这样的问题时先这样做，你可以为自己节省一些麻烦和时间奇怪的“元”错误。至少根据我的经验，这些事情往往来自应该重建但没有重建的旧目标文件。在 MinGW 和常规 GCC 中。

Answer 8

我刚刚遇到了一个类似的问题，在我的例子中，它连接到我的链表数据结构中的指针。当我动态创建一个新列表而不初始化结构内的所有指针时，我的程序在GDB之外崩溃了

这是我原来的数据结构：

typedef struct linked_list {
    node *head;
    node *tail;
} list;

typedef struct list_node {
    char *string;
    struct list_node *next;
} node;

当我创建 list 的新“实例”并指定其 head 和 tail 时，程序在 DGB 外部崩溃：

list *createList(void) {
    list *newList = (list *) malloc(sizeof(list));
    if (newList == NULL) return;

    return newList;
}

在我将createList 函数更改为此之后，一切都开始正常工作了：

list *createList(void) {
    list *newList = (list *) malloc(sizeof(list));
    if (newList == NULL) return;

    newList->head = (node *) 0;
    newList->tail = (node *) 0;

    return newList;
}

希望在遇到与我的示例类似的未初始化指针的情况时，它可能对某人有所帮助。

Answer 9

当您使用 gdb 运行代码时，它会四处移动。现在，您之前尝试引用的非法地址——导致段错误的地址——突然变得合法了。这肯定是一种痛苦。但我所知道的追查此类错误的最佳方法是开始在各处放置 printf()s，逐渐缩小范围。