[Python-Dev] possible fix for recursive call segfault (original) (raw)

Brett Cannon brett at python.org
Tue Apr 18 02:34:16 CEST 2006

• Previous message: [Python-Dev] pdb segfaults in 2.5 trunk?
• Next message: [Python-Dev] possible fix for recursive __call__ segfault
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Bug 532646 is a check for recursive call methods where it is just set to an instance of the same class::

class A: pass A.call = A() a = A() try: a() # This should not segfault except RuntimeError: pass else: raise TestFailed, "how could this not have overflowed the stack?"

Turns out this was never handled for new-style classes and thus goes back to 2.4 at least. I don't know if this is a good solution or not, but I came up with this as a quick fix::

Index: Objects/typeobject.c

--- Objects/typeobject.c (revision 45499) +++ Objects/typeobject.c (working copy) @@ -4585,6 +4585,11 @@

    if (meth == NULL)
            return NULL;

•   if (meth == self) {

•           PyErr_SetString(PyExc_RuntimeError,

•                           "recursive __call__ definition");

•           return NULL;

•   }
    res = PyObject_Call(meth, args, kwds);
    Py_DECREF(meth);
    return res;

Of course SF is down (can't wait until the summer when I can do more tracker work) so I can't post there at the moment. But does anyone think there is a better solution to this without some counter somewhere to keep track how far one goes down fetching call attributes?

-Brett

• Previous message: [Python-Dev] pdb segfaults in 2.5 trunk?
• Next message: [Python-Dev] possible fix for recursive __call__ segfault
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

More information about the Python-Dev mailing list