You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
subprocess.py throw "The handle is invalid" error on duplicating the STD_INPUT_HANDLE #60662
bpo-3905: subprocess failing in GUI applications on Windows
Files
subprocess.zip: Test files to reproduce the issue and patch
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee=Noneclosed_at=<Date2015-12-05.19:44:48.218>created_at=<Date2012-11-12.02:49:27.405>labels= ['type-bug', 'OS-windows']
title='subprocess.py throw "The handle is invalid" error on duplicating the STD_INPUT_HANDLE'updated_at=<Date2015-12-05.19:44:48.217>user='https://bugs.python.org/kartlee05'
Please download subprocess.zip and extract the archive. Run -
perl test.pl
you will notice 'invalid handle' error on duplicating STD_INPUT_HANDLE in python. This is observed in Windows XP SP3. Vista SP2 and higher platforms doesn't show this failure when I checked.
"test.pl" spawn a python process "test.py" using CREATE_NEW_PROCESS_GROUP flag. Before it does, it close STDIN and create a listening socket. Perl under the hood, convert the socket handle to file descriptor using open_osfhandle(..) call. When it does this, the C runtime set the standard input handle to this descriptor for console app. [ See msvcr* osfinfo.c code - SetStdHandle( STD_INPUT_HANDLE, (HANDLE)value ) ]. As a result, when you get the STD_INPUT_HANDLE, you will get the new one. Duplicating this handle, hence throw the invalid handle error in Windows XP SP3.
When I looked at MSDN for DuplicateHandle(..), it is mentioned not to duplicate socket handle using this call. So I suspect something going wrong in XP platform. To fix this issue, I have come up with a patch - python-2143_patch. Please take a look and let me know your comments.
I'm sorry, but I genuinely can't see what you're trying to say here. If you believe that there's a bug in Python's standard library, can you show a reproducible *Python* testcase for it, please (using the pywin32 modules if that helps) and state clearly what you think is wrong.
kartlee05 commented on Nov 13, 2012
kartlee05mannequin
MannequinAuthor
More actions
Hi Tim,
Thanks for your reply.
I added test case using perl and python since it was easy to reproduce using perl socket module and show the issue happening with python's subprocess.py. There is definitely an action required in subprocess.py to catch 'invalid handle error' and my attached patch handle this situation.
I can come up with a test case like perl does to create a listening socket and map the socket handle to a file descriptor. You will see this issue *only* when the open_osfhandle(..) is used to map the handle to a file descriptor.
I added test case using perl and python since it was easy to
reproduce using perl socket module and show the issue happening with
python's subprocess.py. There is definitely an action required in
subprocess.py to catch 'invalid handle error' and my attached patch
handle this situation.
So, because subprocess.call includes a call to DuplicateHandle(stdin),
that call will fail if stdin is currently a handle to a socket.
Is that right?
Your patch fails to apply cleanly to the hg tip, because Gregory P.
Smith has been making changes in this very piece of code over the last
few days. I'll add him as interested to the call as someone who can make
a call as to the suitability of your patch.
I can come up with a test case like perl does to create a listening
socket and map the socket handle to a file descriptor. You will see
this issue *only* when the open_osfhandle(..) is used to map the
handle to a file descriptor.
If this is to go ahead, we will need a test case which can run as part
of the Python stdlib tests, and perl is not part of that stdlib!
kartlee05 commented on Nov 14, 2012
kartlee05mannequin
MannequinAuthor
More actions
Hi Tim,
Thanks for your reply.
Yes, DuplicateHandle(..) seem to fail if the handle is to a socket under XP SP3.
Can you point me to the guidelines about submitting patch so I can merge my change in main branch and upload it?
We build python from source and doesn't use pywin32 as of now. So I downloaded them yesterday to come up with a test case in python which you can use in your test bed.
Activity
kartlee05 commentedon Nov 12, 2012
Please download subprocess.zip and extract the archive. Run -
perl test.pl
you will notice 'invalid handle' error on duplicating STD_INPUT_HANDLE in python. This is observed in Windows XP SP3. Vista SP2 and higher platforms doesn't show this failure when I checked.
"test.pl" spawn a python process "test.py" using CREATE_NEW_PROCESS_GROUP flag. Before it does, it close STDIN and create a listening socket. Perl under the hood, convert the socket handle to file descriptor using open_osfhandle(..) call. When it does this, the C runtime set the standard input handle to this descriptor for console app. [ See msvcr* osfinfo.c code - SetStdHandle( STD_INPUT_HANDLE, (HANDLE)value ) ]. As a result, when you get the STD_INPUT_HANDLE, you will get the new one. Duplicating this handle, hence throw the invalid handle error in Windows XP SP3.
When I looked at MSDN for DuplicateHandle(..), it is mentioned not to duplicate socket handle using this call. So I suspect something going wrong in XP platform. To fix this issue, I have come up with a patch - python-2143_patch. Please take a look and let me know your comments.
-Karthik
tjguk commentedon Nov 13, 2012
I'm sorry, but I genuinely can't see what you're trying to say here. If you believe that there's a bug in Python's standard library, can you show a reproducible *Python* testcase for it, please (using the pywin32 modules if that helps) and state clearly what you think is wrong.
kartlee05 commentedon Nov 13, 2012
Hi Tim,
Thanks for your reply.
I added test case using perl and python since it was easy to reproduce using perl socket module and show the issue happening with python's subprocess.py. There is definitely an action required in subprocess.py to catch 'invalid handle error' and my attached patch handle this situation.
I can come up with a test case like perl does to create a listening socket and map the socket handle to a file descriptor. You will see this issue *only* when the open_osfhandle(..) is used to map the handle to a file descriptor.
-Karthik
tjguk commentedon Nov 14, 2012
On 13/11/2012 20:57, Karthk Rajagopalan wrote:
So, because subprocess.call includes a call to DuplicateHandle(stdin),
that call will fail if stdin is currently a handle to a socket.
Is that right?
Your patch fails to apply cleanly to the hg tip, because Gregory P.
Smith has been making changes in this very piece of code over the last
few days. I'll add him as interested to the call as someone who can make
a call as to the suitability of your patch.
If this is to go ahead, we will need a test case which can run as part
of the Python stdlib tests, and perl is not part of that stdlib!
kartlee05 commentedon Nov 14, 2012
Hi Tim,
Thanks for your reply.
Yes, DuplicateHandle(..) seem to fail if the handle is to a socket under XP SP3.
Can you point me to the guidelines about submitting patch so I can merge my change in main branch and upload it?
We build python from source and doesn't use pywin32 as of now. So I downloaded them yesterday to come up with a test case in python which you can use in your test bed.
-Karthik
tjguk commentedon Nov 14, 2012
Start here: http://docs.python.org/devguide/
In particular: http://docs.python.org/devguide/patch.html
gpshead commentedon Nov 14, 2012
Sorry I can't help on the windows side of things. I don't have access to any windows systems.
tjguk commentedon Nov 15, 2012
Karthk, if you can run up an up-to-date patch and a test I'm willing to review and commit it, otherwise this one will lie quiet.
BreamoreBoy commentedon Jul 13, 2014
Is XP under Python support now? I'm sure I've read that it isn't but can't find a reference.