[PATCH] Set PYTHONMALLOC in the test suite

[PATCH] Set PYTHONMALLOC in the test suite

[Tom Tromey]

Setting PYTHONMALLOC helped me locate an earlier bug.  It seems to me
that there aren't big downsides to always setting this during testing,
and it might help find other bugs in the future.
---
 gdb/testsuite/lib/gdb.exp | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/gdb/testsuite/lib/gdb.exp b/gdb/testsuite/lib/gdb.exp
index 66c04a2efe2..12a9c59dece 100644
--- a/gdb/testsuite/lib/gdb.exp
+++ b/gdb/testsuite/lib/gdb.exp
@@ -6437,6 +6437,10 @@ proc default_gdb_init { test_file_name } {
     # tests.
     setenv TERM "dumb"
 
+    # This setting helps detect bugs in the Python code and doesn't
+    # seem to have a significant downside for the tests.
+    setenv PYTHONMALLOC malloc_debug
+
     # If DEBUGINFOD_URLS is set, gdb will try to download sources and
     # debug info for f.i. system libraries.  Prevent this.
     if { [is_remote host] } {
-- 
2.40.1

Re: [PATCH] Set PYTHONMALLOC in the test suite

[Sam James]

Tom Tromey via Gdb-patches <gdb-patches@sourceware.org> writes:

> Setting PYTHONMALLOC helped me locate an earlier bug.  It seems to me
> that there aren't big downsides to always setting this during testing,
> and it might help find other bugs in the future.

This looks like a good idea. I was a bit disappointed that Python's
Valgrind integration didn't work for you in that bug, because it's
_supposed_ to detect when running under Valgrind and defer to its
malloc instead of its own, but I guess its own debug malloc is
different.

Anyway, yeah, the only downside is speed and that's not
a problem for tests, especially given they're small.

Re: [PATCH] Set PYTHONMALLOC in the test suite

[Tom Tromey]

>> Setting PYTHONMALLOC helped me locate an earlier bug.  It seems to me
>> that there aren't big downsides to always setting this during testing,
>> and it might help find other bugs in the future.

Sam> This looks like a good idea. I was a bit disappointed that Python's
Sam> Valgrind integration didn't work for you in that bug, because it's
Sam> _supposed_ to detect when running under Valgrind and defer to its
Sam> malloc instead of its own, but I guess its own debug malloc is
Sam> different.

I think the issue here is that the bug is a race, which memcheck
wouldn't find (I didn't try helgrind or whatever).  malloc_debug worked
because it detects GIL violations.

Sam> Anyway, yeah, the only downside is speed and that's not
Sam> a problem for tests, especially given they're small.

I'm going to check this in.  Thanks for your comments.

Tom