classification
Title: Python 3.5.2 crashers (from PyPy)
Type: crash Stage:
Components: Versions: Python 3.5
process
Status: open Resolution:
Dependencies: Superseder:
Assigned To: Nosy List: arigo, brett.cannon, serhiy.storchaka, vstinner
Priority: normal Keywords:

Created on 2016-12-06 11:49 by arigo, last changed 2018-02-25 12:58 by serhiy.storchaka.

Messages (9)
msg282518 - (view) Author: Armin Rigo (arigo) * (Python committer) Date: 2016-12-06 11:49
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.
msg282519 - (view) Author: Armin Rigo (arigo) * (Python committer) Date: 2016-12-06 11:50
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.
msg282520 - (view) Author: Armin Rigo (arigo) * (Python committer) Date: 2016-12-06 11:50
(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.
msg282521 - (view) Author: Armin Rigo (arigo) * (Python committer) Date: 2016-12-06 11:51
(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.
msg282522 - (view) Author: Armin Rigo (arigo) * (Python committer) Date: 2016-12-06 11:51
(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.
msg282523 - (view) Author: Armin Rigo (arigo) * (Python committer) Date: 2016-12-06 11:51
(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)
msg282525 - (view) Author: Armin Rigo (arigo) * (Python committer) Date: 2016-12-06 11:53
(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.
msg282564 - (view) Author: Brett Cannon (brett.cannon) * (Python committer) Date: 2016-12-06 18:30
Victor for C4.
msg312809 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2018-02-25 12:58
C5 is fixed in 3.8 by issue17611.
History
Date User Action Args
2018-02-25 12:58:11serhiy.storchakasetnosy: + serhiy.storchaka
messages: + msg312809
2016-12-06 18:30:07brett.cannonsetnosy: + vstinner, brett.cannon
messages: + msg282564
2016-12-06 12:08:35arigosettype: crash
2016-12-06 11:53:06arigosetmessages: + msg282525
2016-12-06 11:52:43arigosetmessages: - msg282524
2016-12-06 11:52:22arigosetmessages: + msg282524
2016-12-06 11:51:53arigosetmessages: + msg282523
2016-12-06 11:51:23arigosetmessages: + msg282522
2016-12-06 11:51:08arigosetmessages: + msg282521
2016-12-06 11:50:44arigosetmessages: + msg282520
2016-12-06 11:50:22arigosetmessages: + msg282519
2016-12-06 11:49:47arigocreate