4

我在这样的对象中遇到了段错误：

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）之前判断对象是否有效？
4

1 回答 1

-1

从来没有一个 coredump 崩溃调试是一个“黑白”的问题。所以你将无法得到与调试 coredump 有关的问题的确切答案。但是，大多数 coredump 是由于编程错误造成的，这些错误可以分为广泛的领域。我将提供其中一些广泛的领域和一些调试机制——这可能会对您有所帮助。

导致崩溃的编程错误类

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

找出核心转储根本原因的方法

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

！

于 2013-08-12T10:32:00.533 回答