> 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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4