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 eryksun
Recipients Bruno Oliveira, Jeffrey.Kintscher, ZackerySpytz, daveb, eryksun, josh.r, lukasz.langa, ned.deily, paul.moore, steve.dower, tim.golden, vstinner, xflr6, zach.ware
Date 2019-08-23.18:02:22
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
> Should we add a version check as well [1]? I'm not totally comfortable 
> with bitmasking a handle here, but if we only do this additional 
> check on Win7 then I'm okay with it.

A version check should not be necessary. For file objects, setting both handle tag bits has always been a reserved signature for console pseudohandles. Here's the definition in the published console code:

It's mostly vestigial in Windows 8+ due to the addition of the ConDrv console device. Code that routed calls to LPC-based implementations when passed a console pseudohandle has all been removed. The only remaining use I know of is in the console attach code. If a process is started with STARTF_USESTDHANDLES, then AllocConsole() will only replace handles that are NULL or console pseudohandles. The docs for GetStdHandle explain this:

    Attach/detach behavior

    When attaching to a new console, standard handles are always replaced
    with console handles unless STARTF_USESTDHANDLES was specified during
    process creation.

    If the existing value of the standard handle is NULL, or the existing
    value of the standard handle looks like a console pseudohandle, the
    handle is replaced with a console handle.

    When a parent uses both CREATE_NEW_CONSOLE and STARTF_USESTDHANDLES to
    create a console process, standard handles will not be replaced unless
    the existing value of the standard handle is NULL or a console

I confirmed that this is still relevant in Windows 10 by testing an inherited pipe handle in stdout and stderr and manually setting the tag bits in the hStdError handle value in STARTUPINFO. The console attach code preserved the regular handle in stdout but replaced the console pseudohandle in stderr. So the API is still reserving these tag bits in file handles, at least in one place, which means they're still reserved in general, even though setting them will no longer break a ReadFile call, for one example, like it would in Windows 7 (in which the API would route the call to the internal ReadConsole implementation). 

We've been relying on checking the console pseudohandle tag bits without a version check in subprocess.Popen._filter_handle_list for a while now. Console pseudohandles have to be removed from the handle list, else CreateProcessW will fail.
Date User Action Args
2019-08-23 18:02:23eryksunsetrecipients: + eryksun, paul.moore, vstinner, tim.golden, ned.deily, lukasz.langa, zach.ware, steve.dower, josh.r, xflr6, Bruno Oliveira, ZackerySpytz, Jeffrey.Kintscher, daveb
2019-08-23 18:02:23eryksunsetmessageid: <>
2019-08-23 18:02:23eryksunlinkissue37549 messages
2019-08-23 18:02:22eryksuncreate