[Bug python/13316] New: (cpychecker) Suspected memory leak ingdb/python/py-param.c: compute_enum_values

["dmalcolm at redhat dot com" <sourceware-bugzilla at sourceware dot org>]

http://sourceware.org/bugzilla/show_bug.cgi?id=13316

             Bug #: 13316
           Summary: (cpychecker) Suspected memory leak in
                    gdb/python/py-param.c: compute_enum_values
           Product: gdb
           Version: HEAD
            Status: NEW
          Severity: normal
          Priority: P2
         Component: python
        AssignedTo: unassigned@sourceware.org
        ReportedBy: dmalcolm@redhat.com
    Classification: Unclassified


Created attachment 6018
  --> http://sourceware.org/bugzilla/attachment.cgi?id=6018
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).

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.