can gdb show the variable being destructed? - c++

Question

Example:
#include <assert.h>
int v = 0;
struct Foo {
Foo() { ++v; }
~Foo()
{
--v;
assert(v != 1); // artificially stop the debugger here
}
};
int main()
{
Foo a; // assert in destructor here?
Foo b; // assert in destructor here?
Foo c; // assert in destructor here?
return 0;
} // main()
This code asserts. I think the debugger should be able to tell me which line/instance of Foo is asserting, but it only shows that it's exiting the scope of main():
#6 0x00007ffff7d9ee96 in __GI___assert_fail (assertion=0x555555556019 "v != 1", file=0x555555556010 "main.cpp", line=8,
function=0x555555556004 "Foo::~Foo()") at ./assert/assert.c:101
#7 0x000055555555521c in Foo::~Foo (this=<optimized out>, __in_chrg=<optimized out>) at main.cpp:8
#8 0x00005555555551b6 in main () at main.cpp:17
(gdb) f 8
#8 0x00005555555551b6 in main () at main.cpp:17
17 } // main()
I know the culprit is b, but how can I make gcc tell me?
Is this just a missing feature or is there somethig more fundamental preventing debuggers from showing this information?
If I add a scope for each instance it becomes clear, but I don't think I should have to recompile.
int main()
{
Foo a;
{
Foo b;
{
Foo c;
}
} // <-- backtrace of the assert shows this line
return 0;
}
The same problem exists for members of a class:
class Bar {
Foo a;
Foo b;
Foo c;
};
[EDIT] What I'd really like to see is the debugger stepping back to the line with Foo c; when it returns from main(), then Foo b; etc. Just like what happens in the following example, where the debugger steps through the Baz() lines one at a time before finally entering func().
func(Baz(),
Baz(),
Baz());

Answer 1

but how can I make gcc tell me?
You can't (at least not directly) -- it has no idea that you are interested in this. But you can give each instance of Foo a name it to print the value of this and the name in both constructor and destructor.
You could also get this info from GDB:
Program received signal SIGABRT, Aborted.
__pthread_kill_implementation (threadid=<optimized out>, signo=6, no_tid=no_tid#entry=0) at ./nptl/pthread_kill.c:44
44 ./nptl/pthread_kill.c: No such file or directory.
(gdb) bt
#0 __pthread_kill_implementation (threadid=<optimized out>, signo=6, no_tid=no_tid#entry=0) at ./nptl/pthread_kill.c:44
#1 0x00007ffff7e55d2f in __pthread_kill_internal (signo=<optimized out>, threadid=<optimized out>) at ./nptl/pthread_kill.c:89
#2 __GI___pthread_kill (threadid=<optimized out>, signo=<optimized out>) at ./nptl/pthread_kill.c:89
#3 0x00007ffff7f9ee70 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#4 0x00007ffff7df1472 in __GI_abort () at ./stdlib/abort.c:79
#5 0x00007ffff7df1395 in __assert_fail_base (fmt=<optimized out>, assertion=<optimized out>, file=<optimized out>, line=<optimized out>, function=<optimized out>) at ./assert/assert.c:92
#6 0x00007ffff7dffdf2 in __GI___assert_fail (assertion=0x555555556015 "v != 1", file=0x555555556010 "t.cc", line=10, function=0x555555556004 "Foo::~Foo()") at ./assert/assert.c:101
#7 0x0000555555555200 in Foo::~Foo (this=0x7fffffffd81e, __in_chrg=<optimized out>) at t.cc:10
#8 0x0000555555555183 in main () at t.cc:20
(gdb) fr 8
#8 0x0000555555555183 in main () at t.cc:20
20 } // main()
(gdb) info locals
a = {<No data fields>}
b = {<No data fields>}
c = {<No data fields>}
(gdb) p &a
$1 = (Foo *) 0x7fffffffd81f
(gdb) p &b
$2 = (Foo *) 0x7fffffffd81e <<=== match for this in frame 7
This of course requires that this isn't optimized (as it is in your stack), or that you print the value of this in the destructor.
[EDIT] What I'd really like to see is the debugger stepping back to the line with Foo c; when it returns from main(), then Foo b; etc.
A compiler could in theory do that, but (I suspect) this will be exceedingly confusing to most end-users: "why is the destructor being invoked when I am simply constructing Foo?".