There are several existing issues (e.g. #18748 and #35866) where at least part of the problem is that GNU libc tried to dlopen() `libgcc_s.so` at a moment when that's not safe, e.g. during thread or process shutdown.  This converts a recoverable error into a deadlock or crash.

This is arguably a bug in glibc, but Python can easily work around it by linking the core interpreter (the `python` executable and/or `libpython.so`) with libgcc_s at build time (`-lgcc_s`) on Linux.  It will then be loaded already if and when it's needed, and glibc won't try to load it on demand.

In order for this to be 100% reliable, it needs to be at least theoretically possible for code within the interpreter to call a function defined in libgcc_s.so. `_Unwind_Backtrace` is probably the most practical option.  (See https://refspecs.linuxfoundation.org/LSB_5.0.0/LSB-Core-generic/LSB-Core-generic/baselib--unwind-backtrace.html .)

> This is arguably a bug in glibc, but Python can easily work around it by linking the core interpreter (the `python` executable and/or `libpython.so`) with libgcc_s at build time (`-lgcc_s`) on Linux.  It will then be loaded already if and when it's needed, and glibc won't try to load it on demand.

I fixed the issue differently in bpo-44434.

I mark this issue as a duplicate of bpo-44434.

superseder: _thread module: Remove redundant PyThread_exit_thread() call to avoid glibc fatal error: libgcc_s.so.1 must be installed for pthread_cancel to work

nosy: + vstinner
messages: + msg396677
resolution: duplicate
stage: resolved