| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
After running test-case gdb.python/py-color-leak.exp in a container where I
don't have PYTHONDONTWRITEBYTECODE set, I get:
...
$ ls src/gdb/testsuite/gdb.python/__pycache__/
gdb_leak_detector.cpython-313.pyc
...
Fix this by setting sys.dont_write_bytecode to True in the python scripts
importing the module.
Tested on x86_64-linux.
|
|
We currently have two memory leak tests in gdb.python/ and there's a
lot of duplication between these two.
In the next commit I'd like to add yet another memory leak test, which
would mean a third set of scripts which duplicate the existing two.
And three is where I draw the line.
This commit factors out the core of the memory leak tests into a new
module gdb_leak_detector.py, which can then be imported by each
tests's Python file in order to make writing the memory leak tests
easier.
I've also added a helper function to lib/gdb-python.exp which captures
some of the common steps needed in the TCL file in order to run a
memory leak test.
Finally, I use this new infrastructure to rewrite the two existing
memory leak tests.
What I considered, but ultimately didn't do, is merge the two memory
leak tests into a single TCL script. I did consider this, and for the
existing tests this would be possible, but future tests might require
different enough setup that this might not be possible for all future
tests, and now that we have helper functions in a central location,
the each individual test is actually pretty small now, so leaving them
separate seemed OK.
There should be no change in what is actually being tested after this
commit.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
This updates the copyright headers to include 2025. I did this by
running gdb/copyright.py and then manually modifying a few files as
noted by the script.
Approved-By: Eli Zaretskii <eliz@gnu.org>
|
|
Re-running 'isort' (via pre-commit) showed that the file
py-read-memory-leak.py (from the gdb test suite) needed a small patch.
|
|
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>
|
