[issue7173] Cython compiler run crashes CPython 3.1.1 and 3.2

Benjamin Peterson added the comment: Fixed in r78766. -- resolution: -> fixed status: open -> closed ___ Python tracker ___ ___ Pytho

[issue7173] Cython compiler run crashes CPython 3.1.1 and 3.2

Antoine Pitrou added the comment: > Is it normal that even after the call to next(), the generator frame > contains a reference to the RuntimeError? As long as it's executing the generator it's quite normal. The generator must be able to restore the caller's RuntimeError when interrupted by a

[issue7173] Cython compiler run crashes CPython 3.1.1 and 3.2

Amaury Forgeot d'Arc added the comment: Is it normal that even after the call to next(), the generator frame contains a reference to the RuntimeError? Long explanation: - When the function exits, there is a cycle [parent frame]-> ['it' variable]-> [generator frame]-> [RuntimeError]-> [parent

[issue7173] Cython compiler run crashes CPython 3.1.1 and 3.2

Antoine Pitrou added the comment: > I tried several times to debug it myself, but I don't understand the > exception cleanup macros in ceval.c (UNWIND_EXCEPTION_HANDLER and > friends, new in Py3). If someone can get me set up to debug them, I > can give it another shot. I assume there are a coup

[issue7173] Cython compiler run crashes CPython 3.1.1 and 3.2

Stefan Behnel added the comment: I tried several times to debug it myself, but I don't understand the exception cleanup macros in ceval.c (UNWIND_EXCEPTION_HANDLER and friends, new in Py3). If someone can get me set up to debug them, I can give it another shot. I assume there are a couple of

[issue7173] Cython compiler run crashes CPython 3.1.1 and 3.2

Stefan Behnel added the comment: I'll add a couple of comments about the relevant parts of the code that appears to trigger the crash. The code runs through the parse tree and applies transformations to it. 1) For node matching, we use a dispatcher (in Visitor.py) that looks up methods for n

[issue7173] Cython compiler run crashes CPython 3.1.1 and 3.2

Stefan Behnel added the comment: Looks like this is one of those bugs that run away when you look too close... I can get it to crash reliably for me with the latest py3k branch (and all Python 3.x release versions) when I run the test suite completely, so here's a new recipe. The intention is

[issue7173] Cython compiler run crashes CPython 3.1.1 and 3.2

STINNER Victor added the comment: I'm unable to reproduce the crash. Can someone write a shorter code reproducing the issue? I downloaded Cython tip and applied the patch attached to this issue. I tried py3k, py3k compiled in pydebug mode, python 3.1 branch: none crashed. Should I clear gener

[issue7173] Cython compiler run crashes CPython 3.1.1 and 3.2

Amaury Forgeot d'Arc added the comment: I reproduce the crash on Linux. Some debug prints showed that the failing exception object is "tp_clear'ed", because it belongs to a reference cycle. Now if it is cleared it should not be reachable... -- ___

[issue7173] Cython compiler run crashes CPython 3.1.1 and 3.2

Amaury Forgeot d'Arc added the comment: Sorry, my mistake. Now the prints are there, but the test run without error: Running tests against Cython 0.12.rc1 Python 3.2a0 (py3k, Nov 22 2009, 12:04:23) [MSC v.1500 32 bit (Intel)] HERE1 (None, None, None) HERE2 HERE1 (None, None, None) HERE2 HERE1

[issue7173] Cython compiler run crashes CPython 3.1.1 and 3.2

Stefan Behnel added the comment: The patch is supposed to apply near the end of the class TreeAssertVisitor at the end of the file Cython/TestUtils.py, not in the class NodeTypeWriter. And the test doesn't run (or even import) the extension, it just builds it. -- _

[issue7173] Cython compiler run crashes CPython 3.1.1 and 3.2

Amaury Forgeot d'Arc added the comment: I don't reproduce the problem on Windows. But the class NodeTypeWriter is not even used at all; did I miss something? The test builds a python extension and runs it, successfully it seems. -- nosy: +amaury.forgeotdarc __

[issue7173] Cython compiler run crashes CPython 3.1.1 and 3.2

Stefan Behnel added the comment: I hadn't, but it looks like the 2to3-ed Cython also runs on 3.0 now, so I tested that, but I failed to get the procedure below to crash for me. And that's both in 3.0 *and* 3.1.1! :-/ But I can still provoke the crash in 3.0, 3.0.1, 3.1.1 and the latest 3.2 when

[issue7173] Cython compiler run crashes CPython 3.1.1 and 3.2

Antoine Pitrou added the comment: Have you tried using 3.1.0 and even 3.0? -- nosy: +pitrou ___ Python tracker ___ ___ Python-bugs-lis

[issue7173] Cython compiler run crashes CPython 3.1.1 and 3.2

Changes by Arfrever Frehtes Taifersar Arahesis : -- nosy: +Arfrever ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscrib

[issue7173] Cython compiler run crashes CPython 3.1.1 and 3.2

Stefan Behnel added the comment: I should add that the crash doesn't necessarily happen during the first test run, which also converts the Cython source to Py3 using 2to3. However, once that's done, running the test a second time crashes reliably. -- ___

[issue7173] Cython compiler run crashes CPython 3.1.1 and 3.2

New submission from Stefan Behnel : Running the Cython compiler under Python 3.1.1 and 3.2 (SVN) corrupts PyThreadState->exc_value by leaving a dead reference. Printing the value then leads to a crash. This bug is about plain Python code, no Cython built extension modules involved. Steps to rep