Re: [Python-Dev] possible fix for recursive __call__ segfault
Hi Brett,
On Mon, Apr 17, 2006 at 05:34:16PM -0700, Brett Cannon wrote:
+ if (meth == self) {
+ PyErr_SetString(PyExc_RuntimeError,
+ recursive __call__ definition);
+ return NULL;
+ }
This is not the proper way, as it can be worked around with a pair of
objects whose __call__ point to each other. The solution is to use the
counter of Py_{Enter,Leave}RecursiveCall(), as was done for old-style
classes (see classobject.c).
By the way, this is a known problem: the example you show is
Lib/test/crashers/infinite_rec_3.py, and the four other
infinite_rec_*.py are all slightly more subtle ways to trigger a similar
infinite loop in C. They point to the SF bug report at
http://python.org/sf/1202533, where we discuss the problem in general.
Basically, someone should try to drop many
Py_{Enter,Leave}RecursiveCall() pairs in the source until all the
currently-known bugs go away, and then measure if this has a noticeable
performance impact.
A bientot,
Mr. 8 Of The 12 Files In That Directory
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] possible fix for recursive __call__ segfault
On 4/18/06, Armin Rigo [EMAIL PROTECTED] wrote:
Hi Brett,
On Mon, Apr 17, 2006 at 05:34:16PM -0700, Brett Cannon wrote:
+ if (meth == self) {
+ PyErr_SetString(PyExc_RuntimeError,
+ recursive __call__ definition);
+ return NULL;
+ }
This is not the proper way, as it can be worked around with a pair of
objects whose __call__ point to each other.
Yeah, I know. It was just a quick hack that at least helped me
identify where the problem was. I didn't really expect for it to
stick around.
The solution is to use the
counter of Py_{Enter,Leave}RecursiveCall(), as was done for old-style
classes (see classobject.c).
OK. Makes sense.
By the way, this is a known problem: the example you show is
Lib/test/crashers/infinite_rec_3.py, and the four other
infinite_rec_*.py are all slightly more subtle ways to trigger a similar
infinite loop in C. They point to the SF bug report at
http://python.org/sf/1202533, where we discuss the problem in general.
Basically, someone should try to drop many
Py_{Enter,Leave}RecursiveCall() pairs in the source until all the
currently-known bugs go away, and then measure if this has a noticeable
performance impact.
OK, good to know. I will have to fix this eventually for sandboxing
reasons for my dissertation so I will get to it eventually.
-Brett
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] possible fix for recursive __call__ segfault
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
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
