aboutsummaryrefslogtreecommitdiff
path: root/r
diff options
context:
space:
mode:
authorAndrew Burgess <aburgess@redhat.com>2025-08-24 21:09:40 +0100
committerAndrew Burgess <aburgess@redhat.com>2025-08-26 15:52:05 +0100
commit0a507079473c5a48be7affbc790c304ecb5ada3e (patch)
tree920bcba13cb2beeeb9f92ec25d440a86dc3859a2 /r
parentaa2b674af942a4d9defa1a1d53707684dd393095 (diff)
downloadbinutils-0a507079473c5a48be7affbc790c304ecb5ada3e.zip
binutils-0a507079473c5a48be7affbc790c304ecb5ada3e.tar.gz
binutils-0a507079473c5a48be7affbc790c304ecb5ada3e.tar.bz2
gdb/python: fix an unlikely memory leak
I noticed a possible memory leak in gdbpy_create_ptid_object, in py-infthread.c. We create a Tuple, and hold the reference in a 'PyObject*' local. If we then fail to create any of the tuple contents we perform an early exit, returning nullptr, this will leak the Tuple object. Currently, we create the Tuple as the first action in the function, but we don't really need the tuple until the end of the function. In this commit I have: 1. Moved creation of the Tuple until the end of the function, just before we need it. 2. Stored the Tuple reference in a gdbpy_ref<>. This is not strictly needed any more, but is (I think) good practice as future changes to the function will not need to worry about releasing the Tuple object. 3. Taken the opportunity to replace a NULL with nullptr in this function. 4. Inlined the local variable declarations to the point of first use. There should be no user visible changes after this commit. No tests as I have no idea how to make gdb_py_object_from_longest (and friends) fail, and so trigger the memory leak. I suspect we'd never actually see this leak in the real world, but it doesn't hurt to clean these things up. Approved-By: Simon Marchi <simon.marchi@efficios.com>
Diffstat (limited to 'r')
0 files changed, 0 insertions, 0 deletions