The thread must not receive any signal. If the thread receives a signal,
sem_timedwait() is interrupted and returns EINTR, but in this case,
PyThread_acquire_lock_timed() retries sem_timedwait() and the main thread is
not aware of the signal. The problem is that some tests expect that the main
thread receives the signal, not faulthandler handler, which should be
invisible.
On Linux, the signal looks to be received by the main thread, whereas on
FreeBSD, it can be any thread.
* faulthandler_user() displays the tracebacks of all threads even if it is
unable to get the state of the current thread
* test_faulthandler: only release the GIL in test_gil_released() check
* create check_signum() subfunction
* faulthandler_cancel_dump_tracebacks_later() is responsible to set running
to zero (so we don't need the volatile keyword anymore)
* release locks if PyThread_start_new_thread() fails
assert(thread.running == 0) was wrong in a corner case
Always release the cancel join.
Fix also another corner case: _PyFaulthandler_Fini() called after setting
running variable to zero, but before releasing the join lock.
If the thread releases the join lock before the cancel lock, the thread may
sometimes still be alive at cancel_dump_tracebacks_later() exit. So the cancel
lock may be destroyed while the thread is still alive, whereas the thread will
try to release the cancel lock, which just crash.
Another minor fix: the thread doesn't release the cancel lock if it didn't
acquire it.
bytes on Windows if the file is a TTY to workaround a Windows bug. The Windows
console returns an error (12: not enough space error) on writing into stdout if
stdout mode is binary and the length is greater than 66,000 bytes (or less,
depending on heap usage).
Windows if the file is a TTY to workaround a Windows bug. The Windows console
returns an error (12: not enough space error) on writing into stdout if
stdout mode is binary and the length is greater than 66,000 bytes (or less,
depending on heap usage).