[issue22898] segfault during shutdown attempting to log ResourceWarning

Xavier de Gaye added the comment: Fixed by issue 30697. -- resolution: -> out of date stage: patch review -> resolved status: open -> closed versions: -Python 3.5 ___ Python tracker

[issue22898] segfault during shutdown attempting to log ResourceWarning

Xavier de Gaye added the comment: > We can't just remove PyExc_RecursionErrorInst since this can cause a stack > overflow Please give an example where a stack overflow occurs when PyExc_RecursionErrorInst has been removed. -- ___ Python tracker

[issue22898] segfault during shutdown attempting to log ResourceWarning

Serhiy Storchaka added the comment: The simplest solution -- make BaseException_set_tb(), BaseException_set_context() and BaseException_set_cause() no-ops for PyExc_RecursionErrorInst. -- Added file: http://bugs.python.org/file46940/immutable-recursion-error-inst.diff

[issue22898] segfault during shutdown attempting to log ResourceWarning

Serhiy Storchaka added the comment: The fact that the traceback of PyExc_RecursionErrorInst causes an issue means that PyExc_RecursionErrorInst is used. We can't just remove PyExc_RecursionErrorInst since this can cause a stack overflow or, with merged PR 2035, an infinite loop. Perhaps the s

[issue22898] segfault during shutdown attempting to log ResourceWarning

Changes by Xavier de Gaye : -- nosy: +brett.cannon ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail

[issue22898] segfault during shutdown attempting to log ResourceWarning

Xavier de Gaye added the comment: Antoine asked in PR 1981: > Did you verify the removed code here wasn't needed anymore? Just checked that crasher infinite_rec_2.py (removed by 1e534b5) does not crash with PR 1981. The other crashers listed at 1e534b5 are not valid Python 3.7 code. Does anyo

[issue22898] segfault during shutdown attempting to log ResourceWarning

Xavier de Gaye added the comment: With PR 1981, a ResourceWarning is printed when a RecursionError occurs while normalizing another exception and its traceback holds a reference to a non-closed file object. For information, issue 5437 removed the MemoryError singleton for the same reasons as

[issue22898] segfault during shutdown attempting to log ResourceWarning

Changes by Xavier de Gaye : -- pull_requests: +2049 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mai

[issue22898] segfault during shutdown attempting to log ResourceWarning

STINNER Victor added the comment: The issue #17852 is still alive and has a reference to this issue. It would be nice to rebase the latest patch on master and create a PR ;-) -- ___ Python tracker

[issue22898] segfault during shutdown attempting to log ResourceWarning

Xavier de Gaye added the comment: Victor, With warn_5.patch *filename is not set when globals is NULL: setup_context() returns 0, and so do_warn() returns NULL without calling warn_explicit(). This is different from your initial warn.patch where setup_context() returns 1 in that case and an a

[issue22898] segfault during shutdown attempting to log ResourceWarning

STINNER Victor added the comment: warn_5.patch: The patch cannot be reviewed on Rietveld :-( You must not use the git format for diff. warn_5.patch: "if (globals == NULL) { (...) return 0; }" It looks like filename is not initialized. I suggest to use: *filename = f->f_code->co_filename;

[issue22898] segfault during shutdown attempting to log ResourceWarning

Xavier de Gaye added the comment: When tested with runtimerror_singleton_3.py (see msg 231933 above), the latest Python 3.6.0a0 (default:3eec7bcc14a4, Mar 24 2016, 20:16:19) still crashes: $ python runtimerror_singleton_3.py Importing mymodule. Traceback (most recent call last): File "runtime

[issue22898] segfault during shutdown attempting to log ResourceWarning

STINNER Victor added the comment: I tried the following script on Python 3.5 and Python 3.6 and I failed to reproduce the bug: --- import sys, traceback class MyException(Exception): def __init__(self, *args): 1/0 def gen(): f = open(__file__, mode='rb', buffering=0) yield

[issue22898] segfault during shutdown attempting to log ResourceWarning

Changes by Xavier de Gaye : Added file: http://bugs.python.org/file37334/setup.py ___ Python tracker ___ ___ Python-bugs-list mailing list Uns

[issue22898] segfault during shutdown attempting to log ResourceWarning

Xavier de Gaye added the comment: When tstate->overflowed is already set to 1 before entering PyErr_NormalizeException() to normalize an exception, the following cases may occur: 1) Normalizing a built-in exception => instantiation ok. 2) Normalizing a python exception that fails with a bui

[issue22898] segfault during shutdown attempting to log ResourceWarning

Changes by Xavier de Gaye : Added file: http://bugs.python.org/file37333/mymodule.c ___ Python tracker ___ ___ Python-bugs-list mailing list U

[issue22898] segfault during shutdown attempting to log ResourceWarning

Xavier de Gaye added the comment: Out of curiosity I have tried to figure out how to build another test case using the model provided by runtimerror_singleton.py. This cannot be done, and for the following reasons: The infinite recursion of PyErr_NormalizeException() is supposed to occur as f

[issue22898] segfault during shutdown attempting to log ResourceWarning

Xavier de Gaye added the comment: > out can be b'Done.\r\n'. Use self.assertIn. Ok, new patch attached. >> If both patches were to be included, the test case in warn_4.patch would >> test the above patch and not the changes made in Python/_warnings.c. > You can test err for warning message.

[issue22898] segfault during shutdown attempting to log ResourceWarning

A. Jesse Jiryu Davis added the comment: With warn_4.patch applied I can no longer reproduce my original segfault, looks like the fix works. -- ___ Python tracker ___ ___

[issue22898] segfault during shutdown attempting to log ResourceWarning

Serhiy Storchaka added the comment: out can be b'Done.\r\n'. Use self.assertIn. > If both patches were to be included, the test case in warn_4.patch would test > the above patch and not the changes made in Python/_warnings.c. You can test err for warning message. The traceback should be clear

[issue22898] segfault during shutdown attempting to log ResourceWarning

Xavier de Gaye added the comment: > Why recursion limit is restored? Couldn't the test be simpler without it? For the sake of explicitness, so that the interpreter will not raise a RuntimeError during finalization when checking for the recursion limit after g.throw(MyException) has raised PyEx

[issue22898] segfault during shutdown attempting to log ResourceWarning

Serhiy Storchaka added the comment: Why recursion limit is restored? Couldn't the test be simpler without it? %a should be used instead of '%s' (file path can contain backslashes). And it would be more robust to open file in binary mode (may be even in non-buffered). It can contain non-ascii c

[issue22898] segfault during shutdown attempting to log ResourceWarning

Xavier de Gaye added the comment: > +/* during Python finalization, warnings may be emited after > interp->sysdict > + is cleared: see issue #22898 */ > > I would prefer to see this comment in the else block. Indeed. New updated patch attached. -- Added file: http://bugs.pyth

[issue22898] segfault during shutdown attempting to log ResourceWarning

STINNER Victor added the comment: +/* during Python finalization, warnings may be emited after interp->sysdict + is cleared: see issue #22898 */ I would prefer to see this comment in the else block. -- ___ Python tracker

[issue22898] segfault during shutdown attempting to log ResourceWarning

Changes by Xavier de Gaye : Added file: http://bugs.python.org/file37279/warn_2.patch ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue22898] segfault during shutdown attempting to log ResourceWarning

Xavier de Gaye added the comment: The attached script raises the PyExc_RecursionErrorInst singleton and reproduces the issue. The attached patch fixes the issue by ignoring the warning when clearing PyExc_RecursionErrorInst and clearing the frames associated with its traceback, in _PyExc_Fini(

[issue22898] segfault during shutdown attempting to log ResourceWarning

STINNER Victor added the comment: Oh, I also wrote a draft of patch fixing the issue, but I was unable to reproduce the issue. See attached warn.patch (not tested). -- keywords: +patch Added file: http://bugs.python.org/file37230/warn.patch ___ Pytho

[issue22898] segfault during shutdown attempting to log ResourceWarning

STINNER Victor added the comment: It looks like the problem is that raising the PyExc_RecursionErrorInst singleton creates a traceback object which contains frames. The singleton keeps the frames alive longer than expected. I tried to write a script to raise this singleton, but it looks like t

[issue22898] segfault during shutdown attempting to log ResourceWarning

Changes by STINNER Victor : -- nosy: +haypo ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python

[issue22898] segfault during shutdown attempting to log ResourceWarning

Serhiy Storchaka added the comment: Looks as globals in setup_context() is NULL. I suppose it is PyThreadState_Get()->interp->sysdict. interp->sysdict is cleared in PyInterpreterState_Clear(). Other code is executed after setting interp->sysdict to NULL (clearing interp->sysdict content, inter

[issue22898] segfault during shutdown attempting to log ResourceWarning

A. Jesse Jiryu Davis added the comment: The crash can ignore whether or not I specify "-Wignore" on the python command line. I was hoping to avoid the crash by short-circuiting the ResourceWarning code path, since the following line appears in the backtrace: #5 PyErr_WarnFormat (category=, s

[issue22898] segfault during shutdown attempting to log ResourceWarning

New submission from A. Jesse Jiryu Davis: Running a unittest suite for Motor, my MongoDB driver which uses PyMongo, greenlet, and Tornado. The suite commonly segfaults during interpreter shutdown. I've reproduced this crash with Python 3.3.5, 3.4.1, and 3.4.2. Python 2.6 and 2.7 do *not* crash