-
-
Notifications
You must be signed in to change notification settings - Fork 32.1k
test_logging: test_post_fork_child_no_deadlock() failed with timeout on AMD64 Arch Linux Asan Debug 3.10 #90867
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
Comments
The test calls support.wait_process() which uses SHORT_TIMEOUT. wait_process() should use LONG_TIMEOUT, or the ASAN buildbot should increase its timeout (regrtest --timeout parameter). IMO using LONG_TIMEOUT is fine: it's ok if the test takes 2 minutes instead of 1 second, it's only important that it completes :-) The test should not measure the *performance* of the code, only if the code is valid. When tests are run in parallel, the buildbot system load can be very high. In this case, the system load was 1.70: 0:35:49 load avg: 1.70 [255/421/1] test_logging failed (1 failure) (1 min 18 sec) AMD64 Arch Linux Asan Debug 3.10: ====================================================================== Traceback (most recent call last):
File "/buildbot/buildarea/3.10.pablogsal-arch-x86_64.asan_debug/build/Lib/test/test_logging.py", line 750, in test_post_fork_child_no_deadlock
support.wait_process(pid, exitcode=0)
File "/buildbot/buildarea/3.10.pablogsal-arch-x86_64.asan_debug/build/Lib/test/support/__init__.py", line 1971, in wait_process
raise AssertionError(f"process {pid} is still running "
AssertionError: process 406366 is still running after 52.5 seconds |
The test.support.wait_process() function now uses a timeout of LONG_TIMEOUT seconds by default, instead of SHORT_TIMEOUT. It doesn't matter if a Python buildbot is slower, it only matters that the process completes. The timeout should just be shorter than "forever".
… (#99098) The test.support.wait_process() function now uses a timeout of LONG_TIMEOUT seconds by default, instead of SHORT_TIMEOUT. It doesn't matter if a Python buildbot is slower, it only matters that the process completes. The timeout should just be shorter than "forever". (cherry picked from commit f09da28)
…ythonGH-99071) (pythonGH-99098) The test.support.wait_process() function now uses a timeout of LONG_TIMEOUT seconds by default, instead of SHORT_TIMEOUT. It doesn't matter if a Python buildbot is slower, it only matters that the process completes. The timeout should just be shorter than "forever". (cherry picked from commit a9a8c87) Co-authored-by: Victor Stinner <[email protected]> (cherry picked from commit f09da28)
) (GH-99098) The test.support.wait_process() function now uses a timeout of LONG_TIMEOUT seconds by default, instead of SHORT_TIMEOUT. It doesn't matter if a Python buildbot is slower, it only matters that the process completes. The timeout should just be shorter than "forever". (cherry picked from commit a9a8c87) Co-authored-by: Victor Stinner <[email protected]> (cherry picked from commit f09da28)
Thanks, looks like we've completed this |
Yep, I fixed it with commit f09da28, backported to 3.11 and 3.10. |
Uh oh!
There was an error while loading. Please reload this page.
test_logging::test_post_fork_child_no_deadlock
#31274Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: