Message339979
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(). |
|
Date |
User |
Action |
Args |
2019-04-11 14:13:42 | vstinner | set | recipients:
+ vstinner, pitrou, ionelmc, neologix, nikicat, zwol, Barry Davis |
2019-04-11 14:13:42 | vstinner | set | messageid: <1554992022.56.0.884465175523.issue18748@roundup.psfhosted.org> |
2019-04-11 14:13:42 | vstinner | link | issue18748 messages |
2019-04-11 14:13:42 | vstinner | create | |
|