[issue28883] Python 3.5.2 crashers (from PyPy)

Serhiy Storchaka added the comment: C5 is fixed in 3.8 by issue17611. -- nosy: +serhiy.storchaka ___ Python tracker ___

[issue28883] Python 3.5.2 crashers (from PyPy)

Brett Cannon added the comment: Victor for C4. -- nosy: +brett.cannon, haypo ___ Python tracker ___ ___

[issue28883] Python 3.5.2 crashers (from PyPy)

Changes by Armin Rigo : -- type: -> crash ___ Python tracker ___ ___

[issue28883] Python 3.5.2 crashers (from PyPy)

Changes by Armin Rigo : -- Removed message: http://bugs.python.org/msg282524 ___ Python tracker ___

[issue28883] Python 3.5.2 crashers (from PyPy)

Armin Rigo added the comment: (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);

[issue28883] Python 3.5.2 crashers (from PyPy)

Armin Rigo added the comment: (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

[issue28883] Python 3.5.2 crashers (from PyPy)

Armin Rigo added the comment: (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. --

[issue28883] Python 3.5.2 crashers (from PyPy)

New submission from Armin Rigo: 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

[issue28883] Python 3.5.2 crashers (from PyPy)

Armin Rigo added the comment: (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);

[issue28883] Python 3.5.2 crashers (from PyPy)

Armin Rigo added the comment: (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

[issue28883] Python 3.5.2 crashers (from PyPy)

Armin Rigo added the comment: (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. -- ___ Python tracker

[issue28883] Python 3.5.2 crashers (from PyPy)

Armin Rigo added the comment: 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