[Python-Dev] What do we do about bad slicing and possible crashes (issue 27867)
Serhiy Storchaka
storchaka at gmail.com
Tue Aug 30 08:13:50 EDT 2016
On 28.08.16 01:25, Terry Reedy wrote:
> 0. Do nothing.
The problem is not in pathological __index__. The problem is in
executing Python code and releasing GIL. In multithread production code
one thread can read a slice when other thread modifies a collection. In
very very rare case it causes a crash (or worse, a corruption of data).
We shouldn't left it as is.
> 1. Detect length change and raise.
It would be simpler solution. But I afraid that this can break
third-party code that "just works" now. For example slicing a list "just
works" if step is 1. It can return not what the author expected if a
list grows, but it never crashes, and existing code can depends on
current behavior. This solution is not applicable in maintained versions.
> 2. Retrieve length after any possible changes and proceed as normal.
This behavior looks the most expectable to me, but needs more work.
> B. Add PySlice_GetIndicesEx2 (or ExEx?), which would receive *collection
> instead of length, so the length could be retrieved after the __index__
> calls. Change calls. Deprecate PySlice_GetIndicesEx.
This is not always possible. The limit for a slice is not always the
length of the collection (see multidimensional arrays). And how to
determine the length? Call __len__? It can be overridden in Python, this
causes releasing GIL, switching to other thread and modifying the
collection. The original problem is returned.
> And what versions should be patched?
Since this is heisenbug that can cause a crash, I think we should apply
some solutions for all versions. But in develop version we a free to
introduce small incompatibility.
I prefer 2A in maintained versions (may be including 3.3 and 3.4) and 2A
or 1A in 3.6.
More information about the Python-Dev
mailing list