summaryrefslogtreecommitdiffstats
path: root/Python/errors.c
diff options
context:
space:
mode:
authorJeremy Hylton <jeremy@alum.mit.edu>2003-04-03 23:02:29 (GMT)
committerJeremy Hylton <jeremy@alum.mit.edu>2003-04-03 23:02:29 (GMT)
commitf95350079cb0e93c57709b1166f969505dfd33a1 (patch)
tree9dae697fd30624b3f27d4082724807b987fb1f61 /Python/errors.c
parent62ed948c2b57b24f60c04390b9f7963c20cedb5a (diff)
downloadcpython-f95350079cb0e93c57709b1166f969505dfd33a1.zip
cpython-f95350079cb0e93c57709b1166f969505dfd33a1.tar.gz
cpython-f95350079cb0e93c57709b1166f969505dfd33a1.tar.bz2
Fix memory corruption in garbage collection.
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.
Diffstat (limited to 'Python/errors.c')
0 files changed, 0 insertions, 0 deletions