Skip to content

Commit 0c8a0b8

Browse files
committed
Re-acquire GIL earlier in gdbpy_parse_and_eval
Tom de Vries filed a bug about an intermittent gdb DAP failure -- and coincidentally, at the same time, Alexandra Hájková sent email about a somewhat similar failure. After looking into this for a while (with no results) using ASan and valgrind, I found that setting PYTHONMALLOC=malloc_debug found the bug instantly. The problem is that gdbpy_parse_and_eval releases the GIL while calling parse_and_eval, but fails to re-acquire it before calling value_to_value_object. This is easily fixed by introducing a new scope. I wonder whether the test suite should unconditionally set PYTHONMALLOC=malloc_debug. Tested-by: Tom de Vries <[email protected]> Reviewed-By: Tom de Vries <[email protected]> Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30686
1 parent 95b8356 commit 0c8a0b8

File tree

1 file changed

+10
-2
lines changed

1 file changed

+10
-2
lines changed

gdb/python/python.c

Lines changed: 10 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -994,9 +994,17 @@ gdbpy_parse_and_eval (PyObject *self, PyObject *args, PyObject *kw)
994994
PyObject *result = nullptr;
995995
try
996996
{
997-
gdbpy_allow_threads allow_threads;
998997
scoped_value_mark free_values;
999-
struct value *val = parse_and_eval (expr_str, flags);
998+
struct value *val;
999+
{
1000+
/* Allow other Python threads to run while we're evaluating
1001+
the expression. This is important because the expression
1002+
could involve inferior calls or otherwise be a lengthy
1003+
calculation. We take care here to re-acquire the GIL here
1004+
before continuing with Python work. */
1005+
gdbpy_allow_threads allow_threads;
1006+
val = parse_and_eval (expr_str, flags);
1007+
}
10001008
result = value_to_value_object (val);
10011009
}
10021010
catch (const gdb_exception &except)

0 commit comments

Comments
 (0)