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_signal.test_without_siginterrupt() sporadic failures on FreeBSD 6.4 #56572
Comments
====================================================================== Traceback (most recent call last):
File "/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Lib/test/test_signal.py", line 396, in test_siginterrupt_on
self.assertTrue(i)
AssertionError: False is not true http://www.python.org/dev/buildbot/all/builders/x86%20FreeBSD%206.4%203.x/builds/1586/steps/test/logs/stdio |
Seen also on OpenSolaris: test test_signal failed -- Traceback (most recent call last):
File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/test/test_signal.py", line 399, in test_siginterrupt_on
self.assertTrue(i)
AssertionError: False is not true |
I tried to patch the test to use a semaphore, but my patch was not reliable (don't remove completly the race condition). Here is a patch using a subprocess to:
It is also based on time: it uses alarm() to raise a signal in one second, and use an hardcoded timeout of 3 seconds. But it doesn't need tricky synchronization between two processes. |
The patch looks good to me. |
New changeset 968b9ff9a059 by Victor Stinner in branch 'default': |
Something outside my code may exit Python with the code 0. Even if it unlikely, I prefer to use uncommon exit codes, to ensure that the child process executed "correctly" my code. A better check would be to write a specific pattern to stdout, and check stdout, but it would be overkill.
(Hum, points 1 and 3: "have only one thread" and "not touch signal handling of the parent process".) True, but I would like to write a more reliable test, and I don't know how to synchronize two processes for this test case. Because your first sentence was "The patch looks good to me.", let's try this new test in our buildbots. |
The test still fails on FreeBSD 7.2, Tiger and Debian parallel: """ Traceback (most recent call last):
File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/test/test_signal.py",
line 379, in test_siginterrupt_on
self.assertTrue(interrupted)
AssertionError: False is not true ====================================================================== Traceback (most recent call last):
File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/test/test_signal.py",
line 372, in test_without_siginterrupt
self.assertTrue(interrupted)
AssertionError: False is not true
""" Here's a sample strace output on my Linux box when it fails: 2120 21:00:18.755448 rt_sigaction(SIGALRM, {0x810b332, [], 0}, NULL, sigaction is called without SA_RESTART, but the syscall is restarted anyway... |
Duh, don't know what I was thinking: the syscall is not restarted |
New changeset aff0a7b0cb12 by Victor Stinner in branch 'default': |
The previous version of the test rarely failed (only sometimes on the FreeBSD 6.4 buildbox). We may revert my commits to restore the previous test if the new tests fail more often.
Right, I added a basic synchronization code to wait until the beginning of the test. Let see if it is better or worse ;-) |
All Python 3.x buildbots are green (except FreeBSD 7.2, but it's not related to this issue). Let close this issue. |
New changeset 8250f04d5a41 by Victor Stinner in branch '3.2': |
New changeset 3f30cfe51315 by Victor Stinner in branch '3.2': New changeset 423268537083 by Victor Stinner in branch 'default': |
Note: 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: