[issue30697] segfault in PyErr_NormalizeException() after memory exhaustion

Ned Deily added the comment: It's been three months since Anthony raised the question about whether this was an acceptable ABI change in 3.6.4. Since then, I am not aware of any reports of problems this has caused and there has been no agreement that it is a critical

[issue30697] segfault in PyErr_NormalizeException() after memory exhaustion

Ned Deily added the comment: I don't know what the right answer here is. But since there don't seem to be strong opinions one way or the other with regard to 3.7, I am not going to hold 3.7.0b1 for a resolution. -- priority: release blocker -> deferred blocker

[issue30697] segfault in PyErr_NormalizeException() after memory exhaustion

Brett Cannon added the comment: No opinion from me on how critical this is. -- ___ Python tracker ___

[issue30697] segfault in PyErr_NormalizeException() after memory exhaustion

Ned Deily added the comment: We should make a decision on this for both 3.6.5 and for 3.7.0. Victor, Antoine, Brett, Serhiy, any opinions? -- ___ Python tracker

[issue30697] segfault in PyErr_NormalizeException() after memory exhaustion

Xavier de Gaye added the comment: As a reference the discussion about the removal of PyExc_RecursionErrorInst took place at PR 1981. The new PR 4941 restores PyExc_RecursionErrorInst on 3.6, not sure if this should be merged. The same operation could be done on 3.7. Python

[issue30697] segfault in PyErr_NormalizeException() after memory exhaustion

Change by Xavier de Gaye : -- pull_requests: +4833 stage: resolved -> patch review ___ Python tracker ___

[issue30697] segfault in PyErr_NormalizeException() after memory exhaustion

Brett Cannon added the comment: Re-opened as a release blocker to make sure we're okay with the potential ABI breakage. -- nosy: +ned.deily priority: normal -> release blocker status: closed -> open ___ Python tracker

[issue30697] segfault in PyErr_NormalizeException() after memory exhaustion

Anthony Sottile added the comment: Should this have landed in python3.6? It removes a public symbol `PyExc_RecursionErrorInst` (abi break?) -- nosy: +Anthony Sottile ___ Python tracker

[issue30697] segfault in PyErr_NormalizeException() after memory exhaustion

Change by Xavier de Gaye : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___

[issue30697] segfault in PyErr_NormalizeException() after memory exhaustion

Xavier de Gaye added the comment: New changeset 4b27d51222be751125e6800453a39360a2dec11d by xdegaye in branch '3.6': [3.6] bpo-30697: Fix PyErr_NormalizeException() when no memory (GH-2327). (#4135)

[issue30697] segfault in PyErr_NormalizeException() after memory exhaustion

Change by Xavier de Gaye : -- keywords: +patch pull_requests: +4098 stage: -> patch review ___ Python tracker ___

[issue30697] segfault in PyErr_NormalizeException() after memory exhaustion

Xavier de Gaye added the comment: New changeset 56d1f5ca32892c7643eb8cee49c40c1644f1abfe by xdegaye in branch 'master': bpo-30697: Fix PyErr_NormalizeException() when no memory (GH-2327) https://github.com/python/cpython/commit/56d1f5ca32892c7643eb8cee49c40c1644f1abfe

[issue30697] segfault in PyErr_NormalizeException() after memory exhaustion

Xavier de Gaye added the comment: Checking the test_exceptions test cases that are added by PR 2327 on the current master branch, before the merge of PR 2327: * test_recursion_normalizing_exception still fails (SIGABRT on a debug build and SIGSEGV otherwise) *

[issue30697] segfault in PyErr_NormalizeException() after memory exhaustion

Xavier de Gaye added the comment: PR 2327 lacks the test cases mentionned below for the moment. 1) With PR 2327, the memerr.py script runs correctly: $ ./python /path/to/memerr.py Fatal Python error: Cannot recover from MemoryErrors while normalizing exceptions. Current thread

[issue30697] segfault in PyErr_NormalizeException() after memory exhaustion

Changes by Xavier de Gaye : -- pull_requests: +2376 ___ Python tracker ___ ___

[issue30697] segfault in PyErr_NormalizeException() after memory exhaustion

Brett Cannon added the comment: And hence why you proposed having a counter of 128 (or some number) to prevent the infinite recursion. I think this has gotten sufficiently complicated and into the bowels of CPython itself it might make sense to ask for a reviewer from python-committers (I

[issue30697] segfault in PyErr_NormalizeException() after memory exhaustion

Xavier de Gaye added the comment: The two issues you are refering to are the instruments that are needed to reproduce the problem. The reference to PR 2035 is only made here to argue about the question of the correct way to control the successive calls to PyErr_NormalizeException(). This

[issue30697] segfault in PyErr_NormalizeException() after memory exhaustion

Brett Cannon added the comment: So is PR 2035 a fix for this? This discussion on this exact problem seems to have ended up spanning a couple issues and a PR so I'm losing track of where things sit at the moment. -- ___ Python tracker

[issue30697] segfault in PyErr_NormalizeException() after memory exhaustion

Xavier de Gaye added the comment: Problem b) is IMO a clear demonstration that using tstate->recursion_depth and the PyExc_RecursionErrorInst singleton is not the correct way to control the recursive calls to PyErr_NormalizeException() since the problem here is memory exhaustion, not

[issue30697] segfault in PyErr_NormalizeException() after memory exhaustion

Changes by Xavier de Gaye : -- versions: +Python 3.5, Python 3.6 ___ Python tracker ___

[issue30697] segfault in PyErr_NormalizeException() after memory exhaustion

New submission from Xavier de Gaye: Nosying reviewers of PR 1981 of issue 22898. The memerr.py script segfaults with the following gdb backtrace: #0 0x00550268 in PyErr_NormalizeException (exc=exc@entry=0x7fffdee8, val=val@entry=0x7fffdef0, tb=tb@entry=0x7fffdef8) at