This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author vstinner
Recipients Barry Davis, ionelmc, neologix, nikicat, pitrou, vstinner, zwol
Date 2019-04-11.14:13:42
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
I looked at this old issue. First of all, "" 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 " 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. " 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().
Date User Action Args
2019-04-11 14:13:42vstinnersetrecipients: + vstinner, pitrou, ionelmc, neologix, nikicat, zwol, Barry Davis
2019-04-11 14:13:42vstinnersetmessageid: <>
2019-04-11 14:13:42vstinnerlinkissue18748 messages
2019-04-11 14:13:42vstinnercreate