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
locks cannot be interrupted on OpenBSD #64763
Comments
Hi, I have 2 tests which "failed" on OpenBSD (tested on i386, amd64 and sparc64) in:
====================================================================== Traceback (most recent call last):
File "Lib/test/test_threadsignals.py", line 94, in test_lock_acquire_interruption
self.assertLess(dt, 3.0)
AssertionError: 5.020112991333008 not less than 3.0 ====================================================================== Traceback (most recent call last):
File "Lib/test/test_threadsignals.py", line 122, in test_rlock_acquire_interruption
self.assertLess(dt, 3.0)
AssertionError: 5.0101478099823 not less than 3.0 On the 3 machines it took ~ 5sec. Thanks for your response, Remi. |
No, see this comment: 5s corresponds exactly to the timeout passed to acquire(), which means that it didn't get interrupted, which is precisely the goal of the test. |
arf, sorry for the noise... I didn't seen this. |
What is your OpenBSD version? Before 5.2, there were many issues with signals. |
I'm in -current (5.5-beta). |
So this looks like a bug. When running the test, is faulthandler enabled (--timeout option)? |
I mean an OpenBSD bug. |
Thanks for your response.
It seems yes: ############################################################################################# ====================================================================== Traceback (most recent call last):
File "/home/remi/dev/cpython/Lib/test/test_threadsignals.py", line 94, in test_lock_acquire_interruption
self.assertLess(dt, 3.0)
AssertionError: 5.019763469696045 not less than 3.0 ====================================================================== Traceback (most recent call last):
File "/home/remi/dev/cpython/Lib/test/test_threadsignals.py", line 122, in test_rlock_acquire_interruption
self.assertLess(dt, 3.0)
AssertionError: 5.020080804824829 not less than 3.0 Ran 6 tests in 13.295s FAILED (failures=2) ====================================================================== Traceback (most recent call last):
File "/home/remi/dev/cpython/Lib/test/test_threadsignals.py", line 94, in test_lock_acquire_interruption
self.assertLess(dt, 3.0)
AssertionError: 5.019940614700317 not less than 3.0 ====================================================================== Traceback (most recent call last):
File "/home/remi/dev/cpython/Lib/test/test_threadsignals.py", line 122, in test_rlock_acquire_interruption
self.assertLess(dt, 3.0)
AssertionError: 5.020142078399658 not less than 3.0 Ran 6 tests in 13.293s FAILED (failures=2) ############################################################################################# Do I miss a thing? |
To make test_lock_acquire_interruption and test_rlock_acquire_interruption more reliable, the test should maybe run a fresh Python process to get a well known number of threads. Some Python modules create C threads like Tkinter. faulthandler creates also an hiding C thread, but it is supposed to ignore all signals (it calls pthread_sigmask). @remi: Can you please test interrupt_lock_acquire.py? It should be the same than the unit test, but in a fresh Python process. |
Thanks for your response, this is what I have: $ PYTHONPATH=. ./python ./interrupt_lock_acquire.py
Traceback (most recent call last):
File "./interrupt_lock_acquire.py", line 30, in <module>
raise Exception("dt > 3: dt=%s" % dt)
Exception: dt > 3: dt=5.011708974838257 Remi. |
Well, then it's definitely an OpenBSD bug, and we can't do anything |
Or a different design choice? It looks like the kernel restarts the wait if it was interrupted. "ignore interruptions other than cancelation" "test that sem_timedwait() resumes after handling a signal" POSIX says that "The sem_timedwait() function shall fail if: [EINTR] A signal interrupted this function." Right now, the best we can do is to skip the test on OpenBSD (maybe only on OpenBSD <= 5.4 to see if it changes later). |
New changeset a3d54bb04cbb by Victor Stinner in branch 'default': |
@remi: You may report the feature request to OpenBSD kernel if you want. Until OpenBSD implements it, the test is now skipped in Python. |
Yes, it's done yet. |
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: