c - 如何仅通过内存地址定位bug？

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 将归因于编程错误，这些错误可以分为广泛的领域。我将提供其中一些广泛的领域和一些调试机制——这可能会对您有所帮助。

---

导致崩溃的编程错误类

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

---

挖掘核心转储根本原因的方法

您需要了解 - 从技术上讲，coredump 是一种非法操作，会导致未处理的异常导致崩溃。由于其中大部分与内存处理有关，静态分析工具(如 kloc/PCLint)将捕获几乎 80% 的问题。然后我接下来会在 valgrind/purify 上运行，很可能会发现其余的问题。很少有问题会同时遗漏这两个问题 - 这将是一些与排序/时序相关的代码 - 可以通过 code review 找到。

喂!