[binutils-gdb] Hold the GIL while clearing gdbpy_reggroup_object_map
Tom Tromey
tromey@sourceware.org
Wed Mar 25 17:25:17 GMT 2026
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=bbc133a3083cebcb9d2e010bef47753448d0046f
commit bbc133a3083cebcb9d2e010bef47753448d0046f
Author: Tom Tromey <tromey@adacore.com>
Date: Tue Mar 24 08:59:31 2026 -0600
Hold the GIL while clearing gdbpy_reggroup_object_map
Tom de Vries pointed out that a certain Python test left a core file.
Looking into this, I think the problem is that the GIL is not held
when gdbpy_reggroup_object_map is destroyed.
This patch changes the code to explicitly clear the global while
holding the GIL. This fixed the crash for me.
This also adds a comment to gdbpy_initialize_file to explicitly
mention that the GIL is held while the finalizers are run.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=34013
Reviewed-By: Tom de Vries <tdevries@suse.de>
Diff:
---
gdb/python/py-registers.c | 23 ++++++++++++++++-------
gdb/python/python-internal.h | 4 +++-
2 files changed, 19 insertions(+), 8 deletions(-)
diff --git a/gdb/python/py-registers.c b/gdb/python/py-registers.c
index 44bc53e6a9d..c6e0748e935 100644
--- a/gdb/python/py-registers.c
+++ b/gdb/python/py-registers.c
@@ -80,6 +80,13 @@ struct reggroup_object : public PyObject
extern PyTypeObject reggroup_object_type;
+/* Map from GDB's internal reggroup objects to the Python
+ representation. GDB's reggroups are global, and are never deleted,
+ so using a map like this is safe. Note it is explicitly cleaned at
+ Python shutdown, see gdbpy_finalize_registers. */
+static gdb::unordered_map<const struct reggroup *,gdbpy_ref<>>
+ gdbpy_reggroup_object_map;
+
/* Return a gdb.RegisterGroup object wrapping REGGROUP. The register
group objects are cached, and the same Python object will always be
returned for the same REGGROUP pointer. */
@@ -87,12 +94,6 @@ extern PyTypeObject reggroup_object_type;
static gdbpy_ref<>
gdbpy_get_reggroup (const reggroup *reggroup)
{
- /* Map from GDB's internal reggroup objects to the Python representation.
- GDB's reggroups are global, and are never deleted, so using a map like
- this is safe. */
- static gdb::unordered_map<const struct reggroup *,gdbpy_ref<>>
- gdbpy_reggroup_object_map;
-
/* If there is not already a suitable Python object in the map then
create a new one, and add it to the map. */
if (gdbpy_reggroup_object_map[reggroup] == nullptr)
@@ -433,7 +434,15 @@ gdbpy_initialize_registers ()
return 0;
}
-GDBPY_INITIALIZE_FILE (gdbpy_initialize_registers);
+static void
+gdbpy_finalize_registers ()
+{
+ /* Have to hold the GIL while clearing the global map; this is
+ guaranteed for finalizers. */
+ gdbpy_reggroup_object_map.clear ();
+}
+
+GDBPY_INITIALIZE_FILE (gdbpy_initialize_registers, gdbpy_finalize_registers);
diff --git a/gdb/python/python-internal.h b/gdb/python/python-internal.h
index bdc960ed208..b24b9314994 100644
--- a/gdb/python/python-internal.h
+++ b/gdb/python/python-internal.h
@@ -616,7 +616,9 @@ class gdbpy_initialize_file
There is no error return in this case. This function is only called
when GDB is already shutting down. The function should make a best
- effort to clean up, and then return. */
+ effort to clean up, and then return.
+
+ The GIL will be held while calling the finalizers. */
using gdbpy_finalize_file_ftype = void (*) (void);
More information about the Gdb-cvs
mailing list