Message71154
Antoine,
Thanks for your analysis. I still believe this is a regression for the
case described, but take my opinion with a grain of salt :)
>> looking at the code for _Py_CheckRecursiveCall(), I don't think it
>> is a bug but a feature.
It does seem to be working as designed, if that is a desirable behavior
then this issue should be closed.
> This is actually what happens in your example: when the normal
> recursion limit is hit and a RuntimeError is raised, you
> immediately catch the exception and run into a second infinite
> loop while the normal recursion check is temporarily disabled:
> the N+50 check then does its job.
Except that it wasn't an infinite loop in 2.5 and isn't in trunk: it
terminates on overflower's except. That's why I think this is a
regression. Besides being different behavior, it seems weird to bail out
on a recursion issue instead of dealing with it.
Your showcase is a better way of getting an infinite loop in trunk than
the one I mentioned, but AFAIK we are more comfortable with infinite
loops than with fatal errors. |
|
Date |
User |
Action |
Args |
2008-08-14 21:17:29 | ajaksu2 | set | recipients:
+ ajaksu2, gvanrossum, pitrou |
2008-08-14 21:17:29 | ajaksu2 | set | messageid: <1218748649.72.0.404186663086.issue3555@psf.upfronthosting.co.za> |
2008-08-14 21:17:29 | ajaksu2 | link | issue3555 messages |
2008-08-14 21:17:27 | ajaksu2 | create | |
|