SystemError: 'finally' pops bad exception with python 3.7 (master branch)
#2674
Comments
|
Ok, leaning more towards this being a cpython bug: Applying the following patch 00:35 $ git diff
diff --git a/Python/ceval.c b/Python/ceval.c
index 9f732f56ba..bac90eaacb 100644
--- a/Python/ceval.c
+++ b/Python/ceval.c
@@ -2100,8 +2100,8 @@ _PyEval_EvalFrameDefault(PyFrameObject *f, int throwflag)
goto fast_block_end;
}
else if (status != Py_None) {
- PyErr_SetString(PyExc_SystemError,
- "'finally' pops bad exception");
+ PyErr_SetObject(PyExc_SystemError,
+ status);
Py_DECREF(status);
goto error;
}
leads to being the thing that |
|
does the error happen with |
|
Yes, still happens with It looks like there is a weird every-other pattern: which if you add so pytest seems to be reporting each test twice but finds them just once: The tests that are failing have a surprising number of stacked marks needs_xelatex = pytest.mark.skipif(not check_for('xelatex'),
reason='xelatex + pgf is required')
# test compiling a figure to pdf with xelatex
@needs_xelatex
@pytest.mark.style('default')
@pytest.mark.backend('pgf')
def test_xelatex():
rc_xelatex = {'font.family': 'serif',
'pgf.rcfonts': False}
mpl.rcParams.update(rc_xelatex)
create_figure()
compare_figure('pgf_xelatex.pdf', tol=0)plus an auto-use fixture (which is where the exception is actually being raised) coming from https://github.com/matplotlib/matplotlib/blob/master/lib/matplotlib/testing/conftest.py#L20 @pytest.fixture(autouse=True)
def mpl_test_settings(request):
from matplotlib.testing.decorators import _do_cleanup
# mpl code
try:
yield
finally:
# mpl codeand by write-to-file-debuggig I know that the yield is not raising and the mpl code in the |
|
Thanks @tacaswell for reaching out.
FWIW this is the normal behavior if the test call is passing, but the teardown step is failing. I guess that's what we are seeing there. |
One shot would be to try to gather all code involved in one of the tests demonstrating the issue into a test function and call it directly outside pytest. This might help narrow down the issue. |
|
Should I try to mock up the effects of the fixture machinery, or just the code written top-to-bottom in a 'natural' style? |
|
I would try top-to-bottom first, and if that fails at least move the auto-use portion to an iterator in case the That last bit gave me another idea: change the autouse fixture in the suite to use |
|
Definitely a cpython bug: def import_in_finally_fail():
try:
print('yo')
finally:
import asyncio.queues as aqIt seems to be Thanks for putting up with my noise! |
The Matplotlib (https://github.com/matplotlib/matplotlib) test suite is seeing errors like
We see these both on travis (https://travis-ci.org/matplotlib/matplotlib/jobs/262907186 ) and I can reproduce locally.
Walking the stack in the debugger is all in pytest / py code and in the code path that handles exceptions.
Via debugging-write-to-a-file I am pretty sure that all of the matplotlib specific code is through and there is not an exception.
This may be a upstream python bug, but trying here first with the hope you will be able to help get a more minimal example.
The text was updated successfully, but these errors were encountered: