如何通过内存地址查找错误？

我得到了这样的对象段错误：在gdb调试核心转储文件如何通过内存地址查找错误？

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 */ 
     ... 
    } 
}

的client内存地址是0x40a651c0。我已经尝试了好几次了，地址是一样的。

然后我试图在GDB的bt命令：

(gdb) bt 
#0 0x0804c80e in http_client_reset (
    c=<error reading variable: Cannot access memory at address 0x40a651c0>, 
    [email protected]=<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除外）？

来源

2013-08-12 coanor

尝试在gdb中使用'disass'来反汇编当前函数。不，没有办法确定一个对象在“坏”值时是否有效。 –

那么，你真的只有一个锚：'在http/client.c：170'在那个地方加入额外的调试信息。 –

Valgrind是你的朋友：http://valgrind.org – alk

-1

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

类编程错误导致的崩溃

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

途径联合国地球信息转储根源

你需要明白 - 技术信息转储是造成未处理的异常导致崩溃的非法操作。由于其中大部分与内存处理有关，因此静态分析工具（如kloc/PCLint）将捕获将近80％的问题。然后，我会在valgrind/purify上运行，最有可能会发现问题的其余部分。很少有问题会错过两者 - 这将是一些排序/时序相关的代码 - 可以通过code review找到。

HTH！

来源

2013-08-12 10:32:00

如何通过内存地址查找错误？

回答

相关问题