homepage

As discussed on python-dev, I am creating omnibus issues from the lists of crashers, of wrong-according-to-the-docs, and of strange-behavior-only issues that I found while developing Python 3.5.2 support for PyPy. These occur with CPython 3.5.2 but most of them are likely still here in trunk.
This is the issue containing the crashers.

os.scandir() returns an iterable object that should not be used
 from multiple threads. Doing so can e.g. cause one thread to
 close the dirp while another thread is still using it. This is
 likely to crash. Similarly, the test for (!iterator->dirp) at
 the start of ScandirIterator_iternext() is only done once even
 if the following loop runs two or three times because of "." or
 ".." entries.

(C2) os.scandir() direntry objects should not have stat() called from two
 threads concurrently. It will make two stat objects and leak one of
 them.

(C3) _PyGen_yf() checks the opcode at [f_lasti + 1], which is the next
 opcode that will run when we resume the generator: either it is the
 opcode following the YIELD, or it is exactly YIELD_FROM. It is not
 possible at the moment to write Python code that compiles to a YIELD
 immediately followed by YIELD_FROM, so by chance the two cases are
 correctly distinguished. *However,* the discussion so far assumes
 that the generator is not currently running. If it is (which probably
 doesn't occur in reasonable Python code but can be constructed
 manually), then this checks for example the byte/word that describes
 the argument of the currently running opcode. If we're very unlucky
 this byte has the value 72, which is YIELD_FROM. Total nonsense and
 crashes follow.

(C4) faulthandler: register(): the signal handler, faulthandler_user(),
 changes errno in faulthandler_dump_traceback() but fails to restore it
 if chain=False. This can rarely cause random nonsense in the main
 program.

(C5) setting f_lineno didn't evolve when the rest of the bytecodes evolved,
 which means it is not safe any more::
 import sys
 def f():
 try:
 raise ValueError # line 5
 except ValueError:
 print(42) # line 7
 def my_trace(*args):
 print(args)
 if args[1] == 'line':
 f = args[0]
 if f.f_lineno == 5:
 f.f_lineno = 7
 return my_trace
 sys.settrace(my_trace)
 f()
 sys.settrace(None)

(C6) I didn't try, but it seems that typeobject.c:mro_internal() is prone
 to a refcount crash. It does this::
 old_mro = type->tp_mro;
 ...mro_invoke()... /* might cause reentrance */
 type->tp_mro = new_mro;
 ...
 Py_XDECREF(old_mro);
 This last XDECREF drops the reference held by the previous value of
 ``type->tp_mro`` after we changed it. But ``type->tp_mro`` might have
 changed because of mro_invoke(), which calls pure Python code. If it
 did change, then old_mro is no longer the old value of
 ``type->tp_mro``. The wrong object gets decrefed.

Victor for C4.

C5 is fixed in 3.8 by issue17611.