Alexey Izbyshev <izbys...@ispras.ru> added the comment: >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 ---------- nosy: +izbyshev _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32865> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
