Signal 6 (SIGABRT) when assigning variable to null (C++) - c++

Question

When analyzing a core dumped after a SIGABRT, gdb says that my last line of code executed (before entering library code) is a NULL assignment to a char pointer, as shown below:
gdb:
(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 listing:
12: ...
13: MyObject::~MyObject() {
14: if (this->string != NULL) {
15: delete this->string;
16: this->string = NULL;
17: }
18: }
19: ...
First of all, I do not understand why the line 16 would result in that call stack. It would make more sense if it was a result of the execution of line 15, the one with the delete operator (unless "line 16" represents code executed after the destructor's code to free the memory allocated for that object; just guessing here).
Other than that, can anyone point the way to correctly debug that core?

Answer 1

What type does this->string have? Is it a char array? Then you should use delete [] this->string. Is it a pointer to an object? Then that object is either already deleted and the pointer was not nulled, or the object has never been created and the pointer was left unitialized.

Answer 2

The actual crash happened on this line:
15: delete this->string;
The crash happened due to to call to abort inside __libc_message. That last routine printed a message to your standard error, and the message looked something like
*** glbc detected: double free or heap corruption at ... ***
Use Valgrind or AddressSanitizer: they'll point you straight at the problem.
I do not understand why the line 16 would result in that call stack.
When you are looking at call stack that led to the raise system call, you need to understand that the CALL instruction puts the address of the next instruction to be executed on the stack, before transferring control to the called procedure, and it is that next instruction that GDB shows you in the backtrace (all debuggers do that). That next instruction may be on the current line, the next line, or 20 lines down.

Answer 3

It points to the next line that is about to be executed, which is line 16 in your case, the last executed statement/expression was line 15 and it crashed on that line.
Hard to tell from your posting what is wrong here though.