aboutsummaryrefslogtreecommitdiff
path: root/gdb/varobj.c
diff options
context:
space:
mode:
authorTom Tromey <tromey@adacore.com>2021-07-30 11:18:36 -0600
committerTom Tromey <tromey@adacore.com>2021-08-02 07:46:30 -0600
commit4d0754c5f572b01cf2fe6c8ab292adba83331cbc (patch)
tree71adad0241d4be3751c09966b5f95dda68137c1c /gdb/varobj.c
parentc894449a790e00cf6fcc079a1efce88437472aaf (diff)
downloadgdb-4d0754c5f572b01cf2fe6c8ab292adba83331cbc.zip
gdb-4d0754c5f572b01cf2fe6c8ab292adba83331cbc.tar.gz
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/varobj.c')
-rw-r--r--gdb/varobj.c6
1 files changed, 4 insertions, 2 deletions
diff --git a/gdb/varobj.c b/gdb/varobj.c
index 7928d90..d0c857a 100644
--- a/gdb/varobj.c
+++ b/gdb/varobj.c
@@ -1844,10 +1844,12 @@ varobj::~varobj ()
}
#endif
+ /* This must be deleted before the root object, because Python-based
+ destructors need access to some components. */
+ delete var->dynamic;
+
if (is_root_p (var))
delete var->root;
-
- delete var->dynamic;
}
/* Return the type of the value that's stored in VAR,