[issue28782] SEGFAULT when running a given coroutine

Changes by Donald Stufft : -- pull_requests: +978 ___ Python tracker ___ ___

[issue28782] SEGFAULT when running a given coroutine

Ned Deily added the comment: (Victor also merged this into default branch for 3.7.0 in 6453ff3328b8) -- priority: release blocker -> stage: commit review -> resolved ___ Python tracker

[issue28782] SEGFAULT when running a given coroutine

STINNER Victor added the comment: Martin Richard: "Thank you all for fixing this so quickly, it's been done amazingly fast!" Even if I didn't write the commit a77756e480c2 which introduced the regression, I pushed it and so I felt responsible. It's a good motivation to fix it quickly. So

[issue28782] SEGFAULT when running a given coroutine

Martin Richard added the comment: Thank you all for fixing this so quickly, it's been done amazingly fast! -- ___ Python tracker ___

[issue28782] SEGFAULT when running a given coroutine

STINNER Victor added the comment: Thanks Martin Richard to continue to find (and report!) crazy corner cases ;-) -- resolution: -> fixed status: open -> closed ___ Python tracker

[issue28782] SEGFAULT when running a given coroutine

Roundup Robot added the comment: New changeset 303cedfb9e7a by Victor Stinner in branch '3.6': Fix _PyGen_yf() https://hg.python.org/cpython/rev/303cedfb9e7a -- nosy: +python-dev ___ Python tracker

[issue28782] SEGFAULT when running a given coroutine

Yury Selivanov added the comment: LGTM -- ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue28782] SEGFAULT when running a given coroutine

Serhiy Storchaka added the comment: pygen_yf-2.patch LGTM. Agreed about tests. -- assignee: -> haypo stage: -> commit review ___ Python tracker ___

[issue28782] SEGFAULT when running a given coroutine

STINNER Victor added the comment: Updated patch. I added a NEWS entry and the two assertions from lasti.patch. These assertions are basic sanity checks, not directly related to this issue, they shouldn't harm. A started frame must never go back to the not-started state (f_lasti < 0). Yury:

[issue28782] SEGFAULT when running a given coroutine

Serhiy Storchaka added the comment: I prefer pygen_yf.patch (with addressing Yury's suggestions). It is much simpler, and in any case I want to change f_lasti to count words rather than bytes (issue27129). It would be again -1 at the start. -- ___

[issue28782] SEGFAULT when running a given coroutine

Yury Selivanov added the comment: > f_lasti being -2 has always been my preference, lasti.patch lgtm How about we commit pygen_yf.patch to 3.6 and whatever else in 3.7? lasti.patch is too invasive for 3.6 at this point, -1 for it in 3.6. -- ___

[issue28782] SEGFAULT when running a given coroutine

Demur Rumed added the comment: I had considered this, for some reason I didn't realize code[1] could be equal to YIELD_FROM, felt it'd always be false f_lasti being -2 has always been my preference, lasti.patch lgtm -- ___ Python tracker

[issue28782] SEGFAULT when running a given coroutine

STINNER Victor added the comment: > Another much larger change would be to change f_lasti to -2... Attached lasti.patch implements this idea. I consider that it makes the C code simpler because getting the next instruction (f_lasti + 2) doesn't require a special case anymore. My patch keeps

[issue28782] SEGFAULT when running a given coroutine

STINNER Victor added the comment: It would be nice if Demur Rumed and/or Serhiy Storchaka can review pygen_yf.patch since Demur wrote the wordcode patch and Serhiy reviewed the wordcode patch. -- nosy: +Demur Rumed ___ Python tracker

[issue28782] SEGFAULT when running a given coroutine

Changes by STINNER Victor : -- keywords: +patch Added file: http://bugs.python.org/file45614/pygen_yf.patch ___ Python tracker

[issue28782] SEGFAULT when running a given coroutine

STINNER Victor added the comment: Oh wow, the bug is tricky. _PyGen_yf() checks if the next instruction is YIELD_FROM using code[f_lasti+2]. The problem is that WORDCODE kept f_lasti == -1 for a frame not executed yet: f_lasti+2 is 1 in this case. Problem: code[1] is not an operation code,

[issue28782] SEGFAULT when running a given coroutine

Yury Selivanov added the comment: Wow, Martin, this is a very interesting one. Thanks so much for tracking this down and reducing the test case. So far this doesn't seem to be related to async/await: the interpreter stack seems to enter some strange state under some conditions, and

[issue28782] SEGFAULT when running a given coroutine

Changes by Yury Selivanov : -- nosy: +serhiy.storchaka ___ Python tracker ___ ___

[issue28782] SEGFAULT when running a given coroutine

Ned Deily added the comment: FWIW, hg bisect finds: changeset 103444:a77756e480c2: bad The first bad revision is: changeset: 103444:a77756e480c2 parent: 103442:914a81781291 user:Victor Stinner date:Fri Sep 09 10:17:08 2016 -0700 summary:

[issue28782] SEGFAULT when running a given coroutine

R. David Murray added the comment: I'm marking this as a release blocker since it is a (new) segfault. -- nosy: +ned.deily, r.david.murray priority: normal -> release blocker ___ Python tracker

[issue28782] SEGFAULT when running a given coroutine

New submission from Martin Richard: Hi, I stumbled upon a SEGFAULT while trying Python 3.6.0 on a project using asyncio. I can't really figure out what's happening, so I reduced the original code triggering the bug down to a reproducible case (which looks a bit clunky, sorry). The case has been