This is the mail archive of the
gdb-prs@sourceware.org
mailing list for the GDB project.
[Bug python/13316] New: (cpychecker) Suspected memory leak ingdb/python/py-param.c: compute_enum_values
- From: "dmalcolm at redhat dot com" <sourceware-bugzilla at sourceware dot org>
- To: gdb-prs at sourceware dot org
- Date: Tue, 18 Oct 2011 14:32:46 +0000
- Subject: [Bug python/13316] New: (cpychecker) Suspected memory leak ingdb/python/py-param.c: compute_enum_values
- Auto-submitted: auto-generated
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.