New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
test_faulthandler.py::test_timeout[True] occasionally crashes #7022
Comments
@blueyed also found that it happens on So it's neither CPython or Windows only... Will edit the title.
It seems clear to me that the timeout does trigger so I'm not sure that increasing it will help. For example in the run above:
|
Note that here it looks like it was just "slow on CI", apart from the message where it looks like the timeout is not 1s (but that might be a Python issue).
https://github.com/pytest-dev/pytest/pull/7020/checks?check_run_id=562177373 |
@blueyed OK, worth a try at least. Closing this, will send a new PR just increasing the timeout. |
@bluetech I've actually looked at the test now: the timeout is But it appears to cause some issue then ( |
The ubuntu-pypy failure:
|
When the subprocess crashes, the "1 passed" output is not matched and the test fails -- this seems intended to me? |
It should happen as late as possible before the test runs. Ref: pytest-dev#7022
The test passing is another issue - like you've mentioned before the faulthandler does not actually timeout anything, but only dumps. In the pypy case above it appears to crash while trying to dump the traceback, and therefore the inner pytest output is missing (which would have the "passed"). |
Maybe worth a try still: maybe pytest exits while the traceback is being dumped? |
Increasing the timeout didn't work. |
It should happen as late as possible before the test runs. Ref: #7022
I'm afraid 413ca8a didn't help either. Unless anyone has any other idea, I propose we just skip this test for now for being flaky, as the broken CI is quite annoying. I'll send a PR. |
How about retrying it for now? |
I don't like rerunning on failure (as a concept), personally. |
Me neither. But not running it anymore will not even show when it starts working again then. |
The issue will remain open, if anyone will want to look at it ;) If users start seeing it then we will be able to bisect or debug more hopefully. In any case, whether some code change caused it or not, it's a native code crash, which a Python-level code change can't bring about on its own -- there must be a bug somewhere outside of pytest proper. |
This tests the
faulthandler_timeout
functionality which dumps stacktraces of all threads of tests that run for more than a specified amount of times.The test sometimes crashes with
Windows fatal exception: access violation
while dumping the threads. This is probably a cpython bug.Noticed on both
windows-py35
andwindows-py37
jobs at least. (Update: also onpypy3-ubuntu
).For now I think we should just skip it on Windows, unless anyone has better ideas or ability to investigate. I'll send a PR doing that.
The text was updated successfully, but these errors were encountered: