Memory leak in object comparison

[jacobs99]

BPO	572567
Nosy	@rhettinger
Files	typeobject.diff: One line patch to fix a memoty leak in typeobject.c show_leak.py: Test case, stack trace, and source of leak

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = 'https://github.com/rhettinger'
closed_at = <Date 2002-06-24.13:26:45.000>
created_at = <Date 2002-06-22.19:17:25.000>
labels = ['interpreter-core']
title = 'Memory leak in object comparison'
updated_at = <Date 2002-06-24.13:26:45.000>
user = 'https://bugs.python.org/jacobs99'

bugs.python.org fields:

activity = <Date 2002-06-24.13:26:45.000>
actor = 'rhettinger'
assignee = 'rhettinger'
closed = True
closed_date = None
closer = None
components = ['Interpreter Core']
creation = <Date 2002-06-22.19:17:25.000>
creator = 'jacobs99'
dependencies = []
files = ['527', '528']
hgrepos = []
issue_num = 572567
keywords = []
message_count = 5.0
messages = ['11303', '11304', '11305', '11306', '11307']
nosy_count = 3.0
nosy_names = ['nnorwitz', 'rhettinger', 'jacobs99']
pr_nums = []
priority = 'normal'
resolution = 'fixed'
stage = None
status = 'closed'
superseder = None
type = None
url = 'https://bugs.python.org/issue572567'
versions = ['Python 2.2']

[jacobs99]

There is a rather obscure memory leak caused
by a missing Py_DECREF one of the comparison
function wrappers in typeobject.c. It is obscure only
because it inflates the reference count on methods,
which is why it has gone unnoticed since its inital
checkin on 8/15/2001. Unfortunately, one of my
meta-class experiments triggers this code on
many ephemoral class instances, and thus leaks
heaping chunks of memory (or a heaping number of
little chunks, if you like).

I've attached the simple one line fix, which should
be applied to the next 2.2.x release, and certainly
to the 2.3 CVS tree. To make myself really useful,
I've also audited the rest of typeobject.c to make sure
that all users of 'lookup_method', the source of the
leaked reference, properly handle its results.

[nnorwitz]

Logged In: YES
user_id=33168

Your patch seems correct. There is an INCREF
in lookup_maybe() which is called by lookup_method().
Also, other places which call lookup_method() do the DECREF.

Could you please attach a test case which triggers this
bug?Thanks.

[rhettinger]

Logged In: YES
user_id=80475

I concur.

And, yes, it would it great to have a unittest that fails
before the patch and works afterward (perhaps using the
GC module to demonstrate the leak).

[jacobs99]

Logged In: YES
user_id=459565

I've attached a test case that demonstrates and
detects the leak. There is also a stack trace and
the code that generates the leaked objects included at the
bottom of the test case.

[rhettinger]

Logged In: YES
user_id=80475

Committed patch as:
test_descr.py 1.144 and 1.113.4.19
typeobject.c 2.157 and 2.126.4.17

Closing bug.