STINNER Victor <vstin...@redhat.com> added the comment:
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(). ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue18748> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
