Author izbyshev
Recipients eryksun, izbyshev, paul.moore, steve.dower, tim.golden, zach.ware
Date 2018-02-18.04:30:57
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1518928258.57.0.467229070634.issue32865@psf.upfronthosting.co.za>
In-reply-to
Content
>Also, it has to skip this check if the FD is flagged as a pipe, because a pipe is likely opened in synchronous mode and blocked on a read in the parent, in which case calling GetFileType would deadlock.

Does an FD get flagged as a pipe by calling GetFileType in _open_osfhandle?

Also, it's totally unclear to me how something like GetFileType can interfere with I/O and cause a deadlock.

My summary of this report. There are two issues.

The first is a bug in os.pipe (creation of an inheritable descriptor with non-inheritable underlying handle). This can be fixed by using _open_osfhandle() correctly.

The second is that os.set_inheritable() / _Py_set_inheritable() is broken on Windows because it may put descriptor and handle heritability out-of-sync (as happens e.g. in os.dup(), os.dup2(), _Py_fopen and friends). This is hard to fix because msvcrt doesn't have something like fcntl(F_SETFD) to change _O_NOINHERIT flag (though one nasty thought is to poke msvcrt internal structures like in _PyVerify_fd removed in #23524).

Both issues cause out-of-sync which is usually hidden and harmless because people prefer subprocess.Popen() which doesn't have the ability to propagate msvcrt-level descriptors at all. The issue surfaces itself if pipes and os.spawn* are involved, leading to two types of inconsistency in the child:
1) Bogus "valid" descriptors referring to wrong handles
2) Unexpectedly invalid descriptors and leaked handles
History
Date User Action Args
2018-02-18 04:30:58izbyshevsetrecipients: + izbyshev, paul.moore, tim.golden, zach.ware, eryksun, steve.dower
2018-02-18 04:30:58izbyshevsetmessageid: <1518928258.57.0.467229070634.issue32865@psf.upfronthosting.co.za>
2018-02-18 04:30:58izbyshevlinkissue32865 messages
2018-02-18 04:30:57izbyshevcreate