SystemError during AST parsing (recursion depth mismatch) #10763
Comments
|
The error output of a run, in which the error is not triggered (socket is free): |
|
I don't think there's anything we can do here without the ability to reproduce this. Can you share a minimal reproducing example? |
Zac-HD
added
the
status: needs information
|
Not sure, which ingredient made a difference (could be e.g. docker or python version), but the bug isn't reproducible anymore now, so I'll close this ticket. Thanks anyway and sorry for the noise |
|
Seeing this in a PR. Don't have a minimal reproducer, but if you want to try and take a look at our PR, it seems to reproduce reliably in CI, only on Python 3.11: |
|
The odd thing is that the first test seems to pass, while the second causes this error. The only difference between the tests is |
Zac-HD
added
type: bug
|
I'm having the same issue here with different library (but, currently unable to make a minimal reproducible version)
The error only occurs when more than one test fails with the same error, a single test will properly fail with the expected SyntaxError (of bad XML) edit raising a RuntimeError in our parser every time will lead to the same error. So this has nothing to do with lxml The error occurs inside an asynchronous fixture, still cannot make a minimal example edit 2 switching to python 3.12 (3.12.0b4) somehow fixes the issue |
|
Seems like python/cpython#113035 should fix it which means the next Python point releases - 3.11.8, 3.12.2, 3.13. If this still happens with these releases, we can reopen. |
Sorry in advance for this mess, it's just a weird bug and i could not further boil it down.
Description
In certain cases, the
ast.parse()line in_pytest/_code/source.py:get_statementrange_ast()triggers the followingSystemError(probably trying to parse itself):Setup
debian:bookwormimageplatform linux -- Python 3.11.1, pytest-7.2.1, pluggy-1.0.0 -- /opt/venv/bin/pythonwebtest.http.StoppableWsgi(WebTest==3.0.0,waitress==2.1.2) server and aselenium.webdriver.Remote(selenium==4.8.0) clientpyramid==2.0.1) + sqlalchemy (SQLAlchemy==1.4.46) with sqlite databasesetUp/tearDown(all*.pyccleaned)Details
The error occurs during a
webtest.http.StoppableWsgi.connect(), which callswaitress.wasyncore.dispatcher.bind(), which callssocket.bind(), which throws a<ExceptionInfo OSError(98, 'Address already in use') tblen=8>, which is processed in theast.parse()line in[...]/site-packages/_pytest/_code/source.py:get_statementrange_ast(),[...]/site-packages/webtest/http.py[...]/site-packages/waitress/server.pyast.parse(content, ...)is called not byget_statementrange_ast()itself (probably recursion? not sure how to introspect in the ast module itself), in the end parsing the traceback of pytest. printing the first parametercontentofast.parse(content, ...)results in (each line one call):fairy._reset(pool, transaction_was_reset)pool._dialect.do_rollback(self)dbapi_connection.rollback()fairy._reset(pool, transaction_was_reset)pool._dialect.do_rollback(self)dbapi_connection.rollback()self._dialect.do_terminate(connection)self.do_close(dbapi_connection)dbapi_connection.close()doit(config, session)config.hook.pytest_runtestloop(session=session)self._hookexec(self.name, self.get_hookimpls(), kwargs, firstresult)self._inner_hookexec(hook_name, methods, kwargs, firstresult)outcome.get_result()raise ex[1].with_traceback(ex[2])hook_impl.function(*args)item.config.hook.pytest_runtest_protocol(item=item, nextitem=nextitem)self._hookexec(self.name, self.get_hookimpls(), kwargs, firstresult)self._inner_hookexec(hook_name, methods, kwargs, firstresult)outcome.get_result()raise ex[1].with_traceback(ex[2])hook_impl.function(*args)runtestprotocol(item, nextitem=nextitem)call_and_report(item, "call", log)hook.pytest_runtest_makereport(item=item, call=call)self._hookexec(self.name, self.get_hookimpls(), kwargs, firstresult)self._inner_hookexec(hook_name, methods, kwargs, firstresult)gen.send(outcome)outcome.get_result()raise ex[1].with_traceback(ex[2])hook_impl.function(*args)TestReport.from_item_and_call(item, call)item.repr_failure(excinfo)self._repr_failure_py(excinfo, style=style)fmt.repr_excinfo(self)self.repr_traceback(excinfo_)self.repr_traceback_entry(entry, einfo)self._getentrysource(entry)entry.getsource(self.astcache)ast.parse(content, "source", "exec")During the return of
ast.parse()theSystemErrorthen occurs.The error was gone after
sqlalchemy.enginewithconnect_args={"check_same_thread": False})I recreated the version, in which the error occurs, and the
check_same_thread=Falseseems enough to not trigger the error. The socket Exception is handled as intended then and the test just fails normally. I haven't manage to reproduce the error from scratch though, so i can't provide a minimal example. I also tried to reproduce in on my host (Archlinux,Python 3.10.9), but it did not work, so i thought it could be a docker bug and tried to reproduce it running with valgrind, as it first felt like some memory issue, but it was not reproducible as well then.I guess, that
ast.parse()is not intended to parse itself? Not sure though, why fixing the sqlalchemy errors also fixes the weird handling of the socket exception. And the sqlalchemy errors are handled fine, when the socket is free and the exception is not thrown.Hope this helps to find some underlying issue.
The text was updated successfully, but these errors were encountered: