]> granicus.if.org Git - python/commit
Fix a subtle bug in the trashcan code I added yesterday to
authorGuido van Rossum <guido@python.org>
Wed, 7 Aug 2002 20:42:09 +0000 (20:42 +0000)
committerGuido van Rossum <guido@python.org>
Wed, 7 Aug 2002 20:42:09 +0000 (20:42 +0000)
commit0906e074426fc596cffb157e28be4bf82de62c7b
treee71bd0184a559a446398c68d9227152d5600e3a1
parentae7ef57cba593d6c7eee8d1fd887c98a135770b3
Fix a subtle bug in the trashcan code I added yesterday to
subtype_dealloc().

When call_finalizer() failed, it would return without going through
the trashcan end macro, thereby unbalancing the trashcan nesting level
counter, and thereby defeating the test case (slottrash() in
test_descr.py).  This in turn meant that the assert in the GC_UNTRACK
macro wasn't triggered by the slottrash() test despite a bug in the
code: _PyTrash_destroy_chain() calls the dealloc routine with an
object that's untracked, and the assert in the GC_UNTRACK macro would
fail on this; but because of an earlier test that resurrects an
object, causing call_finalizer() to fail and the trashcan nesting
level to be unbalanced, so _PyTrash_destroy_chain() was never called.
Calling the slottrash() test in isolation *did* trigger the assert,
however.

So the fix is twofold: (1) call the GC_UnTrack() function instead of
the GC_UNTRACK macro, because the function is safe when the object is
already untracked; (2) when call_finalizer() fails, jump to a label
that exits through the trashcan end macro, keeping the trashcan
nesting balanced.
Objects/typeobject.c