| msg31624 - (view) |
Author: toxik (ludvig.ericson) |
Date: 2007-03-22 22:00 |
| When one uses a class that has derived BaseException in one way or another and uses an invalid super() and calls a function upon that object, Python dies with SIGSEGV. Reproduce code: >>> class X(BaseException): ... def __init__(self): ... super(X, self).__init__(self) ... >>> X() Segmentation fault I could reproduce this on two different Python 2.5 installations. This is as much as I could get from gdb: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1211660624 (LWP 30234)] 0xb7ea601c in _PyObject_GC_Malloc () from /usr/lib/libpython2.5.so.1.0 (gdb) bt #0 0xb7ea601c in _PyObject_GC_Malloc () from /usr/lib/libpython2.5.so.1.0 #1 0xb7ea613b in _PyObject_GC_NewVar () from /usr/lib/libpython2.5.so.1.0 #2 0xb7e4abe4 in PyTuple_New () from /usr/lib/libpython2.5.so.1.0 #3 0xb7e4b48d in ?? () from /usr/lib/libpython2.5.so.1.0 #4 0x00000001 in ?? () #5 0x00000000 in ?? () |
|
|
| msg31625 - (view) |
Author: toxik (ludvig.ericson) |
Date: 2007-03-22 22:09 |
| It might be added that this works (throws an exception) in python 2.4 (though, BaseException does not exist there): TypeError: super() argument 1 must be type, not classobj |
|
|
| msg31626 - (view) |
Author: Georg Brandl (georg.brandl) *  |
Date: 2007-03-22 22:37 |
| This is not new in 2.5. That is does not work with super() in 2.4 is because in 2.4 exceptions are old-style classes. Look at this: >>> class X(Exception): ... def __init__(self): ... Exception.__init__(self, self) ... >>> x=X() >>> str(x) [1] 4396 segmentation fault python2.4 The problem is that str(x) calls str(x) etc. |
|
|
| msg55468 - (view) |
Author: Thomas Herve (therve) * |
Date: 2007-08-30 09:18 |
| Here is a patch correcting the problem, with tests. It doesn't have much to do with exception, it's mainly a problem with PyObject_Str and PyObject_Repr, that I corrected with Py_EnterRecursiveCall calls. Maybe the bug should be reclassified, at least the title changed. |
|
|
| msg55484 - (view) |
Author: toxik (ludvig.ericson) |
Date: 2007-08-30 15:23 |
| Minor note: The patch mixes tabs and spaces. AFAIK, PEP 7 says to use four spaces when making new code, and follow suite in legacy, or convert it. |
|
|
| msg55685 - (view) |
Author: Thomas Herve (therve) * |
Date: 2007-09-06 10:15 |
| object.c is already inconsistent about tabs and space :). It may be better to fix it in the commit, not to clutter the patch. But I can provide a new patch if necessary. |
|
|
| msg55690 - (view) |
Author: toxik (ludvig.ericson) |
Date: 2007-09-06 13:35 |
| Hm, may be so. Feel free to change title/severity if you'd like to. |
|
|
| msg55864 - (view) |
Author: Georg Brandl (georg.brandl) * |
Date: 2007-09-12 19:34 |
| Brett, you recently fixed an infinite recursion crasher, right? |
|
|
| msg55871 - (view) |
Author: Brett Cannon (brett.cannon) * |
Date: 2007-09-12 19:52 |
| So the first example (in ) crashes because of infinite recursion with the repr of exceptions:: #7771 0x00065178 in BaseException_repr (self=0x5dc6b8) at Objects/exceptions.c:128 #7772 0x0001d90c in PyObject_Repr (v=0x5dc6b8) at Objects/object.c:362 #7773 0x0008c180 in tuplerepr (v=0x5dad58) at Objects/tupleobject.c:221 The second one in dies because of the str of exceptions:: #3839 0x0001dd88 in PyObject_Str (v=0x5dc6b8) at Objects/object.c:427 #3840 0x00065120 in BaseException_str (self=0x5dc6b8) at Objects/exceptions.c:110 #3841 0x0001dc0c in _PyObject_Str (v=0x5dc6b8) at Objects/object.c:407 Both fail because BaseException uses the str/repr of its arguments to construct what string to return. When it's itself it just goes on forever trying to get the next object's representation. The repr issue might be fixed by looking at how lists catch loops in themselves (don't remember the exact C function). Either way it is not really str/repr that is causing the issue but exceptions for not worrying about possible recursion thanks to using the str/repr of contained objects. |
|
|
| msg55874 - (view) |
Author: Brett Cannon (brett.cannon) * |
Date: 2007-09-12 21:13 |
| OK, so I have attached a possible patch. I found out that tuple.__repr__ didn't do anything to prevent infinite recursion since you can't pull it off from Python code. But obviously C code is another matter. =) Same goes for object.__str__; it didn't think about a type's tp_str doing something that could lead to an infinite recursion. Assigning back to Georg to make sure I am not doing something stupid nor that the approach is to broad by changing _PyObject_Str() and tuple.__repr__ instead of BaseException itself. I have not written tests yet as they are rather difficult to do for what the C code is doing without relying specifically on how exceptions do their __repr__/__str__. |
|
|
| msg55879 - (view) |
Author: Thomas Herve (therve) * |
Date: 2007-09-13 07:10 |
| I think it could be solved both the same way: if tuple repr is wrong, there are probably some other repr code that is wrong too, so fixing PyObject_Repr is safer. |
|
|
| msg56057 - (view) |
Author: Georg Brandl (georg.brandl) * |
Date: 2007-09-20 16:40 |
| I don't have a specific opinion on this; the usage of Py_EnterRecursiveCall/Py_ReprEnter certainly looks correct. |
|
|
| msg56201 - (view) |
Author: Brett Cannon (brett.cannon) * |
Date: 2007-09-30 19:46 |
| Applied in r58288. If I did something stupid or people don't want the overhead they can yell at the commit. =) |
|
|
| msg56202 - (view) |
Author: Brett Cannon (brett.cannon) * |
Date: 2007-09-30 20:37 |
| And fixed in r58289. |
|
|