Strange and hard to reproduce crash

[Fernando Perez]

On 10/30/06, Lisandro Dalcin <dalcinl at gmail.com> 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