diff options
author | Tom Tromey <tromey@adacore.com> | 2021-07-30 11:18:36 -0600 |
---|---|---|
committer | Tom Tromey <tromey@adacore.com> | 2021-08-02 07:46:30 -0600 |
commit | 4d0754c5f572b01cf2fe6c8ab292adba83331cbc (patch) | |
tree | 71adad0241d4be3751c09966b5f95dda68137c1c /gdb/command.h | |
parent | c894449a790e00cf6fcc079a1efce88437472aaf (diff) | |
download | fsf-binutils-gdb-4d0754c5f572b01cf2fe6c8ab292adba83331cbc.zip fsf-binutils-gdb-4d0754c5f572b01cf2fe6c8ab292adba83331cbc.tar.gz fsf-binutils-gdb-4d0754c5f572b01cf2fe6c8ab292adba83331cbc.tar.bz2 |
Avoid crash in varobj deletion
PR varobj/28131 points out a crash in the varobj deletion code. It
took a while to reproduce this, but essentially what happens is that a
top-level varobj deletes its root object, then deletes the "dynamic"
object. However, deletion of the dynamic object may cause
~py_varobj_iter to run, which in turn uses gdbpy_enter_varobj:
gdbpy_enter_varobj::gdbpy_enter_varobj (const struct varobj *var)
: gdbpy_enter (var->root->exp->gdbarch, var->root->exp->language_defn)
{
}
However, because var->root has already been destroyed, this is
invalid.
I've added a new test case. This doesn't reliably crash, but the
problem can easily be seen under valgrind (and, I presume, with ASAN,
though I did not try this).
Tested on x86-64 Fedora 32. I also propose putting this on the GDB 11
branch, with a suitable ChangeLog entry of course.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28131
Diffstat (limited to 'gdb/command.h')
0 files changed, 0 insertions, 0 deletions