Question

我在这样的对象中出现了段错误：

http_client_reset(struct http_client *client) {
    if (client->last_req) {
         /* @client should never be NULL, but weather
            a valid object, I don't know */
        ...
    }
}

通过调试GDB中的核心转储文件，client的内存地址为 0x40a651c0 。我试了几次，地址也一样。

然后我在GDB中尝试了bt命令：

(gdb) bt
#0  0x0804c80e in http_client_reset (
    c=<error reading variable: Cannot access memory at address 0x40a651c0>, 
    c@entry=<error reading variable: Cannot access memory at address 0x40a651bc>)
    at http/client.c:170
Cannot access memory at address 0x40a651bc

没有回溯信息，我grep编辑了我的源代码，http_client_reset上只有一个电话。

如何通过仅内存地址调试此类错误？
在访问其字段（obj == NULL除外）之前，有没有办法判断对象是否有效？

Answer 1

从来没有一个coredump崩溃调试是一个'黑与白'的问题。因此，你无法得到有关调试coredump的问题的确切答案。然而，大多数coredump将归因于编程错误，其可以被分类为广泛的领域。我将提供一些广泛的领域和一些调试机制 - 这可能会对你有所帮助。

导致崩溃的编程错误类

多线程代码 - 在访问公共数据时检查缺少的关键部分。这可能会破坏导致此类崩溃的数据。在您的情况下，您可以检查http_client指针，访问它和CRUD - 创建/读取/更新和删除。
堆损坏 - 在大多数情况下，这将是一个有效的指针，并且由于在另一部分代码中堆的错误处理，这可能导致有效指针被覆盖。想想指针位置内和周围的数组 - ABW等类型的问题很容易导致这个问题。
堆栈损坏 - 这是不太可能的，但很难找到它们。如果您覆盖堆栈数据 - 类似于上面示例中的数组 - 但在堆栈上，则会出现相同的问题。

解除coredump根本原因的方法

你需要明白 - 技术上coredump是一种非法操作，导致未处理的异常导致崩溃。由于大部分内容与内存处理有关，因此静态分析工具（如kloc/PCLint）将捕获近80％的问题。接下来我会在valgrind/purify上运行，并且很可能会发现问题的其余部分。很少有问题错过它们 - 这可能是一些与时序相关的代码 - 可以通过code review找到。

HTH！

如何只通过内存地址定位bug？

1 个答案: