Issue #26154: Add a new private _PyThreadState_UncheckedGet() function which
gets the current thread state, but don't call Py_FatalError() if it is NULL.
Python 3.5.1 removed the _PyThreadState_Current symbol from the Python C API to
no more expose complex and private atomic types. Atomic types depends on the
compiler or can even depend on compiler options. The new function
_PyThreadState_UncheckedGet() allows to get the variable value without having
to care of the exact implementation of atomic types.
Changes:
* Replace direct usage of the _PyThreadState_Current variable with a call to
_PyThreadState_UncheckedGet().
* In pystate.c, replace direct usage of the _PyThreadState_Current variable
with the PyThreadState_GET() macro for readability.
* Document also PyThreadState_Get() in pystate.h
to its signal handlers.
Use also _Py_write_noraise() instead of write() to retry write() if it is
interrupted by a signal (fail with EINTR).
faulthandler.dump_traceback() also calls PyErr_CheckSignals() to call the
Python signal handler if a signal was received.
Issue #23654: Turn off ICC's tail call optimization for the stack_overflow
generator. ICC turns the recursive tail call into a loop.
Patch written by Matt Frank.
_read_null(), because _read_null() cannot be used on AIX. On AIX, reading from
NULL is allowed: the first page of memory is a mapped read-only on AIX.
_read_null() and _sigabrt() don't accept parameters.
- Use _testcapi.raise_signal() in test_signal
- close also os.pipe() file descriptors in some test_signal tests where they
were not closed properly
- Remove faulthandler._sigill() and faulthandler._sigbus(): reuse
_testcapi.raise_signal() in test_faulthandler
instead of creating temporary Unicode string objects
Add also more identifiers in pythonrun.c to avoid temporary Unicode string
objets for the interactive interpreter.
* Set the default value of all_threads arguments to True
* Py_FatalError() dumps all threads, instead of only the current thread
Dump only the current thread is not reliable. In some cases, Python is unable
to retrieve the state of the current thread and so is unable to dump the
traceback. faulthandler keeps a reference to the interpreter and so is always
able to dump the traceback of all threads.
faulthandler.enable(all_threads=True) dumps the tracebacks even if it is not
possible to get the state of the current thread
Create also the get_thread_state() subfunction to factorize the code.
* Write a new test to ensure that dump_tracebacks_later() still works if
it was already called and then cancelled before
* Don't use a variable to check the status of the thread, only rely on locks
* The thread only releases cancel_event if it was able to acquire it (if
the timer was interrupted)
* The main thread always hold this lock. It is only released when
faulthandler_thread() is interrupted until this thread exits, or at Python
exit.
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.