Author: Armin Rigo <ar...@tunes.org>
Branch: extradoc
Changeset: r5705:c602273d9953
Date: 2016-09-18 21:05 +0200
http://bitbucket.org/pypy/extradoc/changeset/c602273d9953/

Log:    updates

diff --git a/planning/py3.5/cpython-crashers.rst 
b/planning/py3.5/cpython-crashers.rst
--- a/planning/py3.5/cpython-crashers.rst
+++ b/planning/py3.5/cpython-crashers.rst
@@ -23,6 +23,15 @@
   threads concurrently.  It will make two stat objects and leak one of
   them.
 
+* _PyGen_yf() checks the opcode at [f_lasti + 1], which is the next
+  opcode that will run when we resume the generator: either YIELD or
+  YIELD_FROM.  But that is only true if 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.
+
 
 Other bugs
 ----------
@@ -57,3 +66,7 @@
   invoked.  This can confuse coverage tools and profilers.  For example,
   in a stack ``f1()->f2()->f3()``, vmprof would show f3() as usually
   called via f2() from f1() but occasionally called directly from f1().
+
+* ceval.c: GET_AITER: calls _PyCoro_GetAwaitableIter(), which might
+  get an exception from calling the user-defined __await__() or checking
+  what it returns; such an exception is completely eaten.
_______________________________________________
pypy-commit mailing list
pypy-commit@python.org
https://mail.python.org/mailman/listinfo/pypy-commit

Reply via email to