Staging
v0.5.1
Revision f95350079cb0e93c57709b1166f969505dfd33a1 authored by Jeremy Hylton on 03 April 2003, 23:02:29 UTC, committed by Jeremy Hylton on 03 April 2003, 23:02:29 UTC
The move_finalizers() routine checks each object in the unreachable
list to see if it has a finalizer.  If it does, it is moved to the
finalizers list.  The collector checks by calling, effectively,
hasattr(obj, "__del__").  The hasattr() call can result in an
arbitrary amount of Python code being run, because it will invoke
getattr hooks on obj.

If a getattr() hook is run from move_finalizers(), it may end up
resurrecting or deallocating objects in the unreachable list.  In
fact, it's possible that the hook causes the next object in the list
to be deallocated.  That is, the object pointed to by gc->gc.gc_next
may be freed before has_finalizer() returns.

The problem with the previous revision is that it followed
gc->gc.gc_next before calling has_finalizer().  If has_finalizer()
gc->happened to deallocate the object FROM_GC(gc->gc.gc_next), then
the next time through the loop gc would point to freed memory.  The
fix is to always follow the next pointer after calling
has_finalizer().

Note that Python 2.3 does not have this problem, because
has_finalizer() checks the tp_del slot and never runs Python code.

Tim, Barry, and I peed away the better part of two days tracking this
down.
1 parent 62ed948
History
File Mode Size
Demo
Doc
Grammar
Include
Lib
Mac
Misc
Modules
Objects
PC
PCbuild
Parser
Python
RISCOS
Tools
.cvsignore -rw-r--r-- 109 bytes
.hgtags -rw-r--r-- 2.4 KB
LICENSE -rw-r--r-- 12.3 KB
Makefile.pre.in -rw-r--r-- 25.9 KB
PLAN.txt -rw-r--r-- 14.1 KB
README -rw-r--r-- 42.5 KB
acconfig.h -rw-r--r-- 7.5 KB
configure -rwxr-xr-x 211.1 KB
configure.in -rw-r--r-- 55.9 KB
install-sh -rwxr-xr-x 5.5 KB
pyconfig.h.in -rw-r--r-- 19.7 KB
setup.py -rw-r--r-- 35.2 KB

README

back to top