[issue28883] Python 3.5.2 crashers (from PyPy)

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

C5 is fixed in 3.8 by issue17611.

--
nosy: +serhiy.storchaka

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28883] Python 3.5.2 crashers (from PyPy)

[Brett Cannon]

Brett Cannon added the comment:

Victor for C4.

--
nosy: +brett.cannon, haypo

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28883] Python 3.5.2 crashers (from PyPy)

[Armin Rigo]

Changes by Armin Rigo :


--
type:  -> crash

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28883] Python 3.5.2 crashers (from PyPy)

[Armin Rigo]

Changes by Armin Rigo :


--
Removed message: http://bugs.python.org/msg282524

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28883] Python 3.5.2 crashers (from PyPy)

[Armin Rigo]

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);

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28883] Python 3.5.2 crashers (from PyPy)

[Armin Rigo]

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 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)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28883] Python 3.5.2 crashers (from PyPy)

[Armin Rigo]

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.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28883] Python 3.5.2 crashers (from PyPy)

[Armin Rigo]

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 them are likely still here in trunk.

This is the issue containing the crashers.

--
messages: 282518
nosy: arigo
priority: normal
severity: normal
status: open
title: Python 3.5.2 crashers (from PyPy)
versions: Python 3.5

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28883] Python 3.5.2 crashers (from PyPy)

[Armin Rigo]

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);

  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.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28883] Python 3.5.2 crashers (from PyPy)

[Armin Rigo]

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 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.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28883] Python 3.5.2 crashers (from PyPy)

[Armin Rigo]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28883] Python 3.5.2 crashers (from PyPy)

[Armin Rigo]

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 start of ScandirIterator_iternext() is only done once even
  if the following loop runs two or three times because of "." or
  ".." entries.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com