[issue11768] test_signals() of test_threadsignals failure on Mac OS X

Changes by STINNER Victor : Added file: http://bugs.python.org/file21703/signal_versionadded.patch ___ Python tracker ___ ___ Python-bugs-list

[issue11768] test_signals() of test_threadsignals failure on Mac OS X

STINNER Victor added the comment: Le lundi 18 avril 2011 à 10:40 +, STINNER Victor a écrit : > Attached patch should fix this issue: > > - signal_handler() and PyErr_SetInterrupt() only call Py_AddPendingCall() on > the first signal (if is_tripped is zero): it should fix the deadlock and

[issue11768] test_signals() of test_threadsignals failure on Mac OS X

STINNER Victor added the comment: > I don't think so, please re-read. Oh, I thought that Py_AddPendingCall() was used to store the pending signal. But no, it asks Python main loop to check which signal has been trigerred, and we can only do it once for all signals. Attached patch should fix

[issue11768] test_signals() of test_threadsignals failure on Mac OS X

STINNER Victor added the comment: > pthread_sigmask() can be used to avoid reentrant call, > but it has no effect on the second case: "signal_handler() > called twice at the same time in two different threads". Same problem if we use sa_mask field of sigaction() (e.g. use sigfillset(&context

[issue11768] test_signals() of test_threadsignals failure on Mac OS X

Antoine Pitrou added the comment: > Antoine: if I understand correctly your patch, if we have a pending > signal, all next signals will be simply ignored. I don't think so, please re-read. -- ___ Python tracker _

[issue11768] test_signals() of test_threadsignals failure on Mac OS X

STINNER Victor added the comment: It looks like pthread_mutex_lock() and pthread_mutex_unlock() are not reentrant on some platforms (in some implementations of the pthread API). Antoine: if I understand correctly your patch, if we have a pending signal, all next signals will be simply ignored

[issue11768] test_signals() of test_threadsignals failure on Mac OS X

Antoine Pitrou added the comment: > The signal handler calls Py_AddPendingCall() which blocks on acquiring > "pending_lock". It blocks in taking the mutex, not on waiting for the condition variable. Otherwise it wouldn't block (microseconds = 0). I think the solution is to protect signal_han

[issue11768] test_signals() of test_threadsignals failure on Mac OS X

STINNER Victor added the comment: > The main thread was waiting test_signals() lock (signalled_all) > while it is was interrupted by a signal. The signal handler calls > Py_AddPendingCall() which blocks on acquiring "pending_lock". Oh, the main thread receives SIGUSR1: the signal handler calls

[issue11768] test_signals() of test_threadsignals failure on Mac OS X

STINNER Victor added the comment: Oh, I reproduced the bug. [3021] test_threadsignals test_signals (test.test_threadsignals.ThreadSignals) ... test_signals: acquire lock (thread -1610559488) test_signals: wait lock (thread -1610559488) send_signals: enter (thread 271595

[issue11768] test_signals() of test_threadsignals failure on Mac OS X

STINNER Victor added the comment: Oh, the traceback only contains one thread, so send_signals() thread was not created or failed very quickly (before its first print instruction). -- ___ Python tracker __

[issue11768] test_signals() of test_threadsignals failure on Mac OS X

STINNER Victor added the comment: jseutter reproduced it after 112 and 49 runs on Snow Leopard using "regrtest.py -F -v --timeout=60 test_threadsignals" command: --- [ 49] test_threadsignals test_interrupted_timed_acquire (test.test_threadsignals.ThreadSignals) ... ok test_lock_acquire_

[issue11768] test_signals() of test_threadsignals failure on Mac OS X

STINNER Victor added the comment: The failure occurs also on Leopard: -- [159/354] test_threadsignals Thread 0x7fff7080f700: File "/Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86-2/build/Lib/test/test_threadsignals.py", line 53 in test_signals File "/Users/pytho

[issue11768] test_signals() of test_threadsignals failure on Mac OS X Tiger

Roundup Robot added the comment: New changeset d14eac872a46 by Victor Stinner in branch 'default': Issue #11768: add debug messages in test_threadsignals.test_signals http://hg.python.org/cpython/rev/d14eac872a46 -- nosy: +python-dev ___ Python track

[issue11768] test_signals() of test_threadsignals failure on Mac OS X Tiger

New submission from STINNER Victor : test_threadsignals hangs on "x86 Tiger 3.x" and "PPC Tiger 3.x": - [279/354] test_threadsignals Thread 0xa000d000: File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/test_threadsignals.py", line 46 in test_signals File "/Users