Message78740
It certainly looks like all direct calls to PyObject_DEL/PyObject_Del
from outside tp_dealloc implementations are going to be broken in
pydebug builds.
Replacing those calls with either Py_DECREF operations (as Victor's
patch does) or direct calls to _Py_Dealloc should get them to do the
right thing.
I'm a little wary of adding calls to _Py_ForgetReference into
PyObject_Del though, since most of the time the reference will already
have been forgotten by the time that PyObject_Del is called. My
suggestion would be:
1. Update the docs on PyObject_Del to specifically warn against using it
for error cleanup after a successful PyObject_New invocation, instead
pointing users of the C API to Py_DECREF. Basically, code that calls
PyObject_Del outside a tp_dealloc method is probably doing something
wrong. Note also that tp_dealloc implementations in such cases will need
to cope with instances that are only partially initialised (e.g. by
using Py_XDECREF instead of Py_DECREF).
2. Fix the instances in the standard library where _Py_Dealloc may be
bypassed by direct calls to PyObject_Del.
The alternative would be to change the pydebug version of PyObject_Del
to check if the reference count on the object is 1 rather than 0. That
should be a pretty good indication that we're dealing with a case of
cleaning up after a failure to fully initialise an object, and we can
call _Py_ForgetReference directly from PyObject_Del, retroactively
making all those direct invocations of PyObject_Del "correct".
Hmm, now that I write that idea down, it doesn't sound nearly as scary
as I thought it would... |
|
Date |
User |
Action |
Args |
2009-01-01 23:44:47 | ncoghlan | set | recipients:
+ ncoghlan, effbot, georg.brandl, jcea, Rhamphoryncus, vstinner, timehorse |
2009-01-01 23:44:46 | ncoghlan | set | messageid: <1230853486.77.0.922088099182.issue3299@psf.upfronthosting.co.za> |
2009-01-01 23:44:46 | ncoghlan | link | issue3299 messages |
2009-01-01 23:44:45 | ncoghlan | create | |
|