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 efiop, eryksun, gregory.p.smith, paul.moore, steve.dower, tim.golden, vstinner, zach.ware
Date 2019-07-01.14:44:50
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1561992290.47.0.829211027107.issue37380@roundup.psfhosted.org>
In-reply-to
Content
> Say a library calls CreateEventW and gets handle 32. It passes this handle to some other library, which uses the event and closes the handle when it no longer needs it. But due to a miscommunication in the documentation, the first library thinks the handle remains open. Now handle 32 is free for reuse, but the library doesn't know this. subprocess.Popen subsequently calls CreateProcessW and gets handle 32. Later on, the library closes handle 32, making it invalid, at least until it gets assigned to some other kernel object.

So yeah, it's a severe bug in an application. An application should not close the wrong handle by mistake :-) 

Thanks for the explanation. So it would be "nice" to backport the change to reduce the impact of such application bug, but it's not really a bug in Python itself. Python cannot fully protect developers for such class of bugs.

On Unix, there is a similar bug with applications trying to close a file descriptor which is already closed. It can lead to very severe bugs (crashes):
https://bugs.python.org/issue18748
History
Date User Action Args
2019-07-01 14:44:50vstinnersetrecipients: + vstinner, gregory.p.smith, paul.moore, tim.golden, zach.ware, eryksun, steve.dower, efiop
2019-07-01 14:44:50vstinnersetmessageid: <1561992290.47.0.829211027107.issue37380@roundup.psfhosted.org>
2019-07-01 14:44:50vstinnerlinkissue37380 messages
2019-07-01 14:44:50vstinnercreate