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

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 PySliceGetIndicesEx2 (or ExEx?), which would receive *collection instead of length, so the length could be retrieved after the index calls. Change calls. Deprecate PySliceGetIndicesEx.

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