I looked at this old issue. First of all, "bug.py" filename is accurate: this program contains a bug, but it's non-obvious.

* the main thread opens a file which gets the file descriptor 3
* a new thread is spawns which indirectly closes this file descriptor on: sys.stdout.close()
* the main thread is not aware that the file has been closed, and so will try to close the same file descriptor 3 sometime during Python shutdown
* then, sometimes, the glibc fails with an internal error because the main thread closed a file descriptor which was just opened by the other thread to implement thread cancellation: that logs "libgcc_s.so.1 must be installed for pthread_cancel to work" and calls abort()

Note: the Python file object remains alive until the "t" local variable is cleared, since "t.fh" contains a strong reference to the file object.

Again: it's a bug in the program. "libgcc_s.so.1 must be installed for pthread_cancel to work" is just *one* example of bad thing that can happen.

What can be do on the Python side? Well, stop to ignore silently I/O errors when a file is closed by its destructor.

I wrote a shy PR 12786 to only log these exceptions in development mode (-X dev). I'm not sure if we could stop to silence these exceptions *by default*.

Python has been modified last years to first raise an exception on I/O errors when file.close() is called explicitly, and then a similar change has been done for call to socket.socket.close().