[Python-Dev] What do we do about bad slicing and possible crashes (issue 27867)

[Serhiy Storchaka]

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.