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.