On 10/30/06, Lisandro Dalcin <[EMAIL PROTECTED]> wrote: > FYI, this is what is defined in Include/object.h > > /* PyObject_HEAD defines the initial segment of every PyObject. */ > #define PyObject_HEAD \ > _PyObject_HEAD_EXTRA \ > Py_ssize_t ob_refcnt; \ > struct _typeobject *ob_type; > > #define Py_INCREF(op) ( \ > _Py_INC_REFTOTAL _Py_REF_DEBUG_COMMA \ > (op)->ob_refcnt++) > > #define Py_DECREF(op) \ > if (_Py_DEC_REFTOTAL _Py_REF_DEBUG_COMMA \ > --(op)->ob_refcnt != 0) \ > _Py_CHECK_REFCNT(op) \ > else \ > _Py_Dealloc((PyObject *)(op)) > > And '_Py_CHECK_REFCNT' macro will finally call Py_FatalError > > 'ob_refcnt' is a Py_ssize_t integer, so I think you will not be able > to overflow it, unless in case of C code with refcounting bugs. Am I > right?
I think you are, and fortunately this indicates that they /did/ change to a longer data type for refcounting in newer pythons. The box where we have this problem is running 2.3 though, and obviously a runaway refcount in f2py can still die even if it's a longer data type. However, Travis mentioned he just fixed precisely a bug like that in f2py, so I'm optimistic, and I'm currently making a new test. Thanks for the info, f ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
