For a long time Fedora GDB has carried an out of tree patch which checks for memory leaks in gdb.Inferior.read_memory(). At one point in the distant past GDB did have a memory leak in this code, but this was first fixed in commit: commit 655e820cf9a039ee55325d9e1f8423796d592b4b Date: Wed Mar 28 17:38:07 2012 +0000 * python/py-inferior.c (infpy_read_memory): Remove cleanups and explicitly free 'buffer' on exit paths. Decref 'membuf_object' before returning. And the code has changed a lot since then, but the leak is still fixed. Unfortunately, this commit didn't have any associated tests. The original Fedora test wasn't really suitable for upstream, it was reading /proc/PID/... to figure out if there was a leak or not. However, we already have gdb.python/py-inferior-leak.exp in upstream GDB, which makes use of the Python tracemalloc module to check for memory leaks in a corner of the Python API, so I figured it wouldn't hurt to rewrite the test in the same style. And so here is a test for a bug which was closed 12 years ago. This detects if the gdb.Inferior.read_memory() call leaks any memory. I've tested this by hacking gdbpy_buffer_to_membuf, replacing the last line which currently looks like this: return PyMemoryView_FromObject ((PyObject *) membuf_obj.get ()); and instead doing: return PyMemoryView_FromObject ((PyObject *) membuf_obj.release ()); The use of "release" here will mean we no longer decrement the reference count on membuf_obj before returning from the function. As a consequence the membuf_obj will not be garbage collected. With this hack in place the new test will fail. The Python script in the new test is mostly a copy&paste from py-inferior-leak.py with the core changed to do a memory read instead of inferior creation. I did consider rewriting both tests into a single file, maybe, py-memory-leak.py, which would make it easier to add additional similar tests in the future. For now I've held off doing that, but if this gets merged then I _might_ revisit this idea. If folk feel that this new test should only be accepted if I do this rewrite then let me know and I can get that done. On copyright date ranges: The .exp and .py scripts are new enough for this commit that I've dated them 2024. The .c source script is lifted directly from the old Fedora patch, so I've retained the original 2014 start date for that file only. Approved-By: Tom Tromey <tom@tromey.com>