Changes by Mark Lawrence breamore...@yahoo.co.uk:
--
resolution: - wont fix
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue2548
___
Mark Lawrence breamore...@yahoo.co.uk added the comment:
This has been fixed in Python 2.7, I suppose that the code could be backported
to 2.6, or is it now too late so this can be closed as won't fix?
--
nosy: +BreamoreBoy
___
Python tracker
Brett Cannon br...@python.org added the comment:
It theoretically could be backported so it can stay open for now if someone
feels adventurous to backport before 2.6.6. Once that's out the door, though,
this can get closed.
--
___
Python tracker
Sean Reifschneider j...@tummy.com added the comment:
The final word on this seems to be this:
- Wait until when we aren't in a beta release. (DONE)
- Quoting:
Well, For Py3K at least we might need to consider going through the C
API and fixing it so that these incorrect
Antoine Pitrou [EMAIL PROTECTED] added the comment:
The crashers which were deleted in rev58032 should at least have been
turned into unittests... well.
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2548
Antoine Pitrou [EMAIL PROTECTED] added the comment:
Ok, here is a patch which seems to cover all bases. It fixes the present
bug, adds tests for the aforementioned ex-crashers, backports the
somewhat smarter recursion checking from py3k, and improves the latter
by fixing a nasty recursion bug
Changes by Antoine Pitrou [EMAIL PROTECTED]:
--
keywords: +needs review
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2548
___
___
Python-bugs-list
Changes by Antoine Pitrou [EMAIL PROTECTED]:
Removed file: http://bugs.python.org/file11313/excrecurse.patch
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2548
___
Antoine Pitrou [EMAIL PROTECTED] added the comment:
Ouch, there were a couple of useless lines in ceval.h. New patch.
Added file: http://bugs.python.org/file11314/excrecurse.patch
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2548
Antoine Pitrou [EMAIL PROTECTED] added the comment:
After thinking about it a bit, I think the whole recursion checking
thing has gone a bit mad. It probably deserves proper discussion on the
mailing-list. In the meantime, I'm downgrading this bug to critical.
--
priority: release
Changes by Benjamin Peterson [EMAIL PROTECTED]:
--
priority: critical - release blocker
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2548
___
___
Antoine Pitrou [EMAIL PROTECTED] added the comment:
For what it's worth, py3k has a subtler recursion checking algorithm
which would probably fix this problem if backported properly. See
_Py_CheckRecursiveCall() in ceval.c (lines 462+), and especially the
role played by the tstate-overflowed
Daniel Diniz [EMAIL PROTECTED] added the comment:
FWIW, rev58032 introduced this:
tstate = PyThreadState_GET();
if (++tstate-recursion_depth Py_GetRecursionLimit()) {
--tstate-recursion_depth;
PyErr_SetObject(PyExc_RuntimeError, PyExc_RecursionErrorInst);
return;
Brett Cannon [EMAIL PROTECTED] added the comment:
On Wed, Aug 13, 2008 at 12:49 PM, Daniel Diniz [EMAIL PROTECTED] wrote:
Daniel Diniz [EMAIL PROTECTED] added the comment:
FWIW, rev58032 introduced this:
tstate = PyThreadState_GET();
if (++tstate-recursion_depth
Benjamin Peterson [EMAIL PROTECTED] added the comment:
Ping
--
nosy: +benjamin.peterson
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2548
___
___
Barry A. Warsaw [EMAIL PROTECTED] added the comment:
This is a bug that can be fixed after beta, so I'm knocking it back to
critical for beta 1.
--
priority: release blocker - critical
___
Python tracker [EMAIL PROTECTED]
Barry A. Warsaw [EMAIL PROTECTED] added the comment:
I'm not going to hold up the 2.6 alpha release for this, but will bump
it up for the first 2.6 beta.
--
nosy: +barry
priority: release blocker - critical
__
Tracker [EMAIL PROTECTED]
Daniel Diniz [EMAIL PROTECTED] added the comment:
I've identified rev58032 [1] as the one introducing this issue. It's
Brett's code, fixing a nasty crasher and adding a pre-built exception
(PyExc_RecursionErrorInst).
[1] http://svn.python.org/view?rev=58032view=rev
P.S.: Thanks Thomas for
Brett Cannon [EMAIL PROTECTED] added the comment:
Neal has the memory of an elephant or something.
Yes, I dealt with a similar issue where the recursion limit was hit, but
then normalizing the exception just caused it to hit it again. I thought
I changed it such that normalizing an exception
New submission from Thomas Heller [EMAIL PROTECTED]:
[Found by Daniel Diniz (ajaksu2), see issue #2542]
The following code triggers an undetected error with a debug build:
import sys
def g():
try:
return g()
except:
return sys.exc_info()
g()
print 42
Running the code prints
Amaury Forgeot d'Arc [EMAIL PROTECTED] added the comment:
Analysis: the primary recursion error is correctly raised, but then
there is a call to PyErr_NormalizeException, which calls
PyEval_CallObject, which increases the stack depth and hit the recursion
limit again...
python2.5 don't have the
Neal Norwitz [EMAIL PROTECTED] added the comment:
Brett, didn't you have a similar problem you fixed a while ago? I
assigned to you for more input, feel free to reset to nobody.
--
assignee: - brett.cannon
nosy: +brett.cannon, nnorwitz
priority: - release blocker
Changes by Daniel Diniz [EMAIL PROTECTED]:
--
nosy: +ajaksu2
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2548
__
___
Python-bugs-list mailing list
Unsubscribe:
23 matches
Mail list logo
