0

在分析 SIGABRT 后转储的核心时，gdb 说我执行的最后一行代码（在进入库代码之前）是NULL对指针的赋值char，如下所示：

数据库：

(gdb) bt full
#0  0x006337a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
No symbol table info available.
#1  0x00674815 in raise () from /lib/tls/libc.so.6
No symbol table info available.
#2  0x00676279 in abort () from /lib/tls/libc.so.6
No symbol table info available.
#3  0x006a8cca in __libc_message () from /lib/tls/libc.so.6
No symbol table info available.
#4  0x006af55f in _int_free () from /lib/tls/libc.so.6
No symbol table info available.
#5  0x006af93a in free () from /lib/tls/libc.so.6
No symbol table info available.
#6  0x00d0b14e in __builtin_delete () from /usr/lib/libstdc++-libc6.1-1.so.2
No symbol table info available.
#7  0x0808181c in MyObject::~MyObject (this=0x84f4db0, __in_chrg=3) at ./MyObject.cpp:16
    this = (MyObject *) 0x84f4db0

MyObject.cpp:16 清单：

12: ...
13: MyObject::~MyObject() {
14:   if (this->string != NULL) {
15:     delete this->string;
16:     this->string = NULL;
17:   }
18: }
19: ...

首先，我不明白为什么第 16 行会导致调用堆栈。如果它是第 15 行的执行结果会更有意义，即带有delete运算符的行（除非“第 16 行”表示在析构函数代码之后执行的代码以释放为该对象分配的内存；只是在这里猜测）。

除此之外，任何人都可以指出正确调试该内核的方法吗？

4

3 回答 3

3

有什么类型this->string？它是一个字符数组吗？那么你应该使用delete [] this->string. 它是指向对象的指针吗？然后该对象要么已被删除且指针未为空，要么该对象从未被创建且指针未初始化。

于 2013-03-12T14:21:04.717 回答
1

实际的崩溃发生在这一行：

15:     delete this->string;

坠机是由于对abort内部的调用而发生的__libc_message。最后一个例程向您的标准错误打印一条消息，该消息看起来像

*** glbc detected: double free or heap corruption at ...  ***

使用Valgrind或AddressSanitizer：他们会直接指出问题所在。

我不明白为什么第 16 行会导致调用堆栈。

当您查看导致raise系统调用的调用堆栈时，您需要了解该CALL指令将下一条要执行的指令的地址放在堆栈上，然后再将控制权转移到被调用的过程，并且正是下一条指令GDB 向您展示backtrace（所有调试器都这样做）。下一条指令可能在当前行、下一行或向下 20 行。

于 2013-03-12T14:27:29.113 回答
0

它指向即将执行的下一行，在您的情况下是第 16 行，最后执行的语句/表达式是第 15 行，它在该行崩溃。

不过，很难从您的帖子中看出这里有什么问题。

于 2013-03-12T14:18:02.823 回答