[Python-Dev] A cute new way to get an infinite loop (original) (raw)
Raymond Hettinger python at rcn.com
Sun Sep 26 12:17:34 CEST 2004
- Previous message: [Python-Dev] A cute new way to get an infinite loop
- Next message: [Python-Dev] A cute new way to get an infinite loop
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
I think it's easy to fix. "The usual rule" applies: you can't assume anything about a mutable object after potentially calling back into Python. So trying to save info in "i", "m", or "n" across loop iterations can't work, and the list can never be left in an insane state ("semi" or not) at any time user code may get invoked. But since we have both "num allocated" and "num used" members in the list struct now, it's easy to use those instead of trying to carry info in locals.
FWIW, I've searched the codebase and found no other variants on this problem. None of the other update/extend methods try to remember self data between iterations. Other calls to list_resize immediately fill-in the NULLS before calling arbitrary Python code. And, other places that use the over-allocation trick, map() for example, are working with a brand new list or tuple that has not been exposed to the rest of the application.
One situation did look suspect. _PySequence_IterSearch() remembers an index/count across calls to PyIter_Next() -- it looks like the worst that could happen is the index or count would be wrong, but no crashers.
Patch attached. Anyone object? Of course in the example at the start of this msg, it leaves x empty.
Looks good. Reads well. Solves the problem. The timings are still fast. The test suite runs w/o exception. Please apply.
Raymond
- Previous message: [Python-Dev] A cute new way to get an infinite loop
- Next message: [Python-Dev] A cute new way to get an infinite loop
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]