Bug 13316 - (cpychecker) Suspected memory leak in gdb/python/py-param.c: compute_enum_values
Summary: (cpychecker) Suspected memory leak in gdb/python/py-param.c: compute_enum_values
Status: RESOLVED FIXED
Alias: None
Product: gdb
Classification: Unclassified
Component: python (show other bugs)
Version: HEAD
: P2 normal
Target Milestone: 7.7
Assignee: Phil Muldoon
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-10-18 14:32 UTC by Dave Malcolm
Modified: 2013-11-01 18:01 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:


Attachments
HTML report showing the execution paths that leak memory (3.90 KB, text/html)
2011-10-18 14:32 UTC, Dave Malcolm
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Dave Malcolm 2011-10-18 14:32:46 UTC
Created attachment 6018 [details]
HTML report showing the execution paths that leak memory

See the attached HTML report from gcc-python-plugin's cpychecker.

It looks like a reference count on "*item" is leaked for each time through the loop in compute_enum_values().

Reading 
  http://docs.python.org/c-api/sequence.html#PySequence_GetItem

a successful call to PySequence_GetItem() is meant to give the caller ownership of a reference count on the returned PyObject*

Double-checking with Python's Objects/abstract.c:
  PyObject *
  PySequence_GetItem(PyObject *s, Py_ssize_t i)
  {
        [... setup and error handling ...]
        return m->sq_item(s, i);
  }

and looking at e.g. Objects/listobject.c: list_item (the sq_item callback for PyList_Type): it Py_INCREFs the returned item.

Hence I believe that cpychecker is correctly reporting a memory leak here (for both the case of a successful execution of compute_enum_values(), and the failure path it shows).
Comment 1 Tom Tromey 2013-11-01 18:01:03 UTC
I fixed this a while back without realizing there was a PR:

2013-05-20  Tom Tromey  <tromey@redhat.com>

	* python/py-param.c (compute_enum_values): Decref 'item'.