spawnl issues with Win 7 access rights

[Propad]

Hello everybody,
I have some trouble with a program I run both on a WinXP and on Win 7.
It boils down to this several lines:

import os
vePath = r'C:\Programme\RA Consulting_Webservices\DiagRA-MCD
\DiagRA_D.exe'
#vePath = r'C:\Windows\notepad.exe'
process_id = os.spawnl(os.P_NOWAIT, vePath)

Under Win XP they open DiagRA just fine; under Win 7 I'm getting:
OSError: [Errno 22] Invalid argument
Needless to say, I checked the path under Win 7; it is correct.

As you can see, I tried the same lines with notepad, just in case;
same result. Works fine under XP, IOError under Win 7.

So I'm pretty sure it's some kind of Win 7 access rights issue... Can
anybody point me to a concise overview of the issues involved, and
maybe even the known solutions? Again, it's os.spawnl in Python 2.2,
under Win 7.

Thank you very much in advance.

Cheers,

Nenad

 

[Tim Golden]

Hello everybody,
I have some trouble with a program I run both on a WinXP and on Win 7.
It boils down to this several lines:

import os
vePath = r'C:\Programme\RA Consulting_Webservices\DiagRA-MCD
\DiagRA_D.exe'
#vePath = r'C:\Windows\notepad.exe'
process_id = os.spawnl(os.P_NOWAIT, vePath)

Under Win XP they open DiagRA just fine; under Win 7 I'm getting:
OSError: [Errno 22] Invalid argument
Needless to say, I checked the path under Win 7; it is correct.

As you can see, I tried the same lines with notepad, just in case;
same result. Works fine under XP, IOError under Win 7.

So I'm pretty sure it's some kind of Win 7 access rights issue... Can
anybody point me to a concise overview of the issues involved, and
maybe even the known solutions? Again, it's os.spawnl in Python 2.2,
under Win 7.

That's impressive. I ran this (on Python 2.7 on Win7):

<code>
import os

os.spawnl (os.P_NOWAIT, r"c:\windows\notepad.exe")

</code>

and Python crashed hard! Long time since I've seen that happen.

This may or may not be related to what you're seeing but it's
definitely a problem. I'll check the bugs database and/or
file a bug.

I *can* reproduce your problem running Python22 on Win7. Now,
no-one's going to be applying patches to Python 2.2 at this
stage: in the 2.x series, only 2.7 is getting anything other
than urgent security fixes. And even 2.7's only getting clear
bugfixes. Just so you know.

Without checking the code, I'm going to assume that the 2.2 codebase
is handing off to the MS C Runtime Library for posix-related calls
such as the spawn* family. So it may not even be Python's code directly
which is returning this error.


TJG

 

[Propad]

Hello Tim,
thanx for the fast answer. Sorry to hear there are such issues.
I'm obviously not free to choose my version of Python, or I'would be
using the latest'n'greatest. It's more like this: I'm obliged to use
the version delivered with dSpace tools (which is HiL - ECU-testing
software for the automotive and aerospace industries).
I'just might be able to use 2.5, which dSpace delivered 2-3 years
ago; but I'm not sure of that, and not sure it would help in any way.
So some solution without tweaking the code or anything would be realy
nice. I can't imagine anything of such importance was not tested at
all during the beta phase - so it could be the tests were not run with
such a tricky configuration of windows.

Any hints are appreciated!

Cheers,
Nenad

Hello everybody,
I have some trouble with a program I run both on a WinXP and on Win 7.
It boils down to this several lines:

import os
vePath = r'C:\Programme\RA Consulting_Webservices\DiagRA-MCD
\DiagRA_D.exe'
#vePath = r'C:\Windows\notepad.exe'
process_id = os.spawnl(os.P_NOWAIT, vePath)

Under Win XP they  open DiagRA just fine; under Win 7 I'm getting:
OSError: [Errno 22] Invalid argument
Needless to say, I checked the path under Win 7; it is correct.

As you can see, I tried the same lines with notepad, just in case;
same result. Works fine under XP, IOError under Win 7.

So I'm pretty sure it's some kind of Win 7 access rights issue... Can
anybody point me to a concise overview of the issues involved, and
maybe even the known solutions? Again, it's os.spawnl in Python 2.2,
under Win 7.

That's impressive. I ran this (on Python 2.7 on Win7):

<code>
import os

os.spawnl (os.P_NOWAIT, r"c:\windows\notepad.exe")

</code>

and Python crashed hard! Long time since I've seen that happen.

This may or may not be related to what you're seeing but it's
definitely a problem. I'll check the bugs database and/or
file a bug.

I *can* reproduce your problem running Python22 on Win7. Now,
no-one's going to be applying patches to Python 2.2 at this
stage: in the 2.x series, only 2.7 is getting anything other
than urgent security fixes. And even 2.7's only getting clear
bugfixes. Just so you know.

Without checking the code, I'm going to assume that the 2.2 codebase
is handing off to the MS C Runtime Library for posix-related calls
such as the spawn* family. So it may not even be Python's code directly
which is returning this error.

TJG- Zitierten Text ausblenden -

- Zitierten Text anzeigen -

 

[Tim Golden]

<code>
import os

os.spawnl (os.P_NOWAIT, r"c:\windows\notepad.exe")

</code>

and Python crashed hard! Long time since I've seen that happen.

This may or may not be related to what you're seeing but it's
definitely a problem. I'll check the bugs database and/or
file a bug.

I *can* reproduce your problem running Python22 on Win7. Now,
no-one's going to be applying patches to Python 2.2 at this
stage: in the 2.x series, only 2.7 is getting anything other
than urgent security fixes. And even 2.7's only getting clear
bugfixes. Just so you know.

OK; the python 2.7 issues is http://bugs.python.org/issue8036

Let's see if I can get a fix in before the next release!

Not quite sure whether the 2.2 issue is the same but it's
looking like being a W7 / CRT-related issue. I'll keep
looking

TJG

 

[Terry Reedy]

Same with 3.2 and Win7, interpreter or IDLE.

OK; the python 2.7 issues is http://bugs.python.org/issue8036

The example there used P_WAIT instead of P_NOWAIT, but I added comment.

 

[Terry Reedy]

On 10/24/2011 9:47 AM, Propad wrote:
y

nice. I can't imagine anything of such importance was not tested at
all during the beta phase - so it could be the tests were not run with
such a tricky configuration of windows.

The coverage of the test suite is still being improved as people
volunteer to write more tests. This mostly happens as part of bug fixing.

 

[Miki Tebeka]

Please use the subprocess module, it's the one who's actively maintained.
http://docs.python.org/library/subprocess.html#replacing-the-os-spawn-family

 

[Propad]

Please use the subprocess module, it's the one who's actively maintained.http://docs.python.org/library/subprocess.html#replacing-the-os-spawn...

Thnx again for all the answers. As stated before, I'm limited in my
options. One of them just might be to switch to Python 2.5, rewrite
the code that crashes using the subprocess module, and then somehow
patch the library I use (which I'm not suposed to do, but... oh
well ). I can just hope subrocess was already mature adn offering
the relevant functionality in 2.5.

Cheers,
Nenad

 

[Tim Golden]

Thnx again for all the answers. As stated before, I'm limited in my
options. One of them just might be to switch to Python 2.5, rewrite
the code that crashes using the subprocess module, and then somehow
patch the library I use (which I'm not suposed to do, but... oh
well ). I can just hope subrocess was already mature adn offering
the relevant functionality in 2.5.

I must admit I'm more than slightly surprised by this. My test case
is to use os.spawnl to run c:/windows/notepad.exe. From the docs,
I would expect to use os.spawnl (os.P_WAIT, "c:/windows/notepad.exe").
(I only want to open notepad.exe; there's no need for additional args).

These are my test cases:

(1)

os.spawnl (
os.P_WAIT,
"c:/windows/notepad.exe"
)

(2)

os.spawnl (
os.P_WAIT,
"c:/windows/notepad.exe",
"c:/windows/notepad.exe"
)

(3)

os.spawnl (
os.P_WAIT,
"c:/windows/notepad.exe",
"c:/windows/notepad.exe",
"c:/temp.txt"
)


And the results:

==============================================================
Python | Platform | Case | Result
--------------------------------------------------------------
2.2.2 | WinXP | 1 | Works (empty notepad)
2.2.2 | WinXP | 2 | Works (empty notepad)
2.2.2 | WinXP | 3 | Works (notepad temp.txt)
--------------------------------------------------------------
2.2.2 | Win7 | 1 | OSError
2.2.2 | Win7 | 2 | Works (empty notepad)
2.2.2 | Win7 | 3 | Works (notepad temp.txt)
--------------------------------------------------------------
2.7.2 | WinXP | 1 | Crashes
2.7.2 | WinXP | 2 | Works (empty notepad)
2.7.2 | WinXP | 3 | Works (notepad temp.txt)
--------------------------------------------------------------
2.7.2 | Win7 | 1 | Crashes
2.7.2 | Win7 | 2 | Works (empty notepad)
2.7.2 | Win7 | 3 | Works (notepad temp.txt)
==============================================================


Add to this a look at the mscrt source which ships with VS 2008
and the MSDN docs for spawnl:

http://msdn.microsoft.com/en-us/library/wweek9sc(v=vs.80).aspx

and we see that the first args parameter must be the same as the
path parameter.

FWIW, at no extra cost, I went to the trouble of testing it on some
flavour of Linux with Python 2.6 and got the same results
as per 2.2.2 on WinXP. (Basically: everything works).

Which leaves us with http://bugs.python.org/issue8036 in which recent
versions of Python crash when the (arbitrary) second parameter isn't
passed. And with an inexplicable behaviour change between the same
version of Python running on WinXP and on Win7.

It looks as though the workaround for your problem (or, possibly,
your failure to fulfil some artificial parameter requirements) is
to add the executable again as the third parameter.

issue8036 (which also affects the execl family) has a patch waiting
for review, which hopefully we can get round to fixing. As far as I
can tell, the execl/spawnl family of functions isn't currently
represented in the testsuite.

TJG

 

[Terry Reedy]

I must admit I'm more than slightly surprised by this. My test case
is to use os.spawnl to run c:/windows/notepad.exe. From the docs,
I would expect to use os.spawnl (os.P_WAIT, "c:/windows/notepad.exe").
(I only want to open notepad.exe; there's no need for additional args).

These are my test cases:

(1)

os.spawnl (
os.P_WAIT,
"c:/windows/notepad.exe"
)

(2)

os.spawnl (
os.P_WAIT,
"c:/windows/notepad.exe",
"c:/windows/notepad.exe"
)

(3)

os.spawnl (
os.P_WAIT,
"c:/windows/notepad.exe",
"c:/windows/notepad.exe",
"c:/temp.txt"
)


And the results:

==============================================================
Python | Platform | Case | Result
--------------------------------------------------------------
2.2.2 | WinXP | 1 | Works (empty notepad)
2.2.2 | WinXP | 2 | Works (empty notepad)
2.2.2 | WinXP | 3 | Works (notepad temp.txt)
--------------------------------------------------------------
2.2.2 | Win7 | 1 | OSError
2.2.2 | Win7 | 2 | Works (empty notepad)
2.2.2 | Win7 | 3 | Works (notepad temp.txt)
--------------------------------------------------------------
2.7.2 | WinXP | 1 | Crashes
2.7.2 | WinXP | 2 | Works (empty notepad)
2.7.2 | WinXP | 3 | Works (notepad temp.txt)
--------------------------------------------------------------
2.7.2 | Win7 | 1 | Crashes
2.7.2 | Win7 | 2 | Works (empty notepad)
2.7.2 | Win7 | 3 | Works (notepad temp.txt)
==============================================================


Add to this a look at the mscrt source which ships with VS 2008
and the MSDN docs for spawnl:

http://msdn.microsoft.com/en-us/library/wweek9sc(v=vs.80).aspx

and we see that the first args parameter must be the same as the
path parameter.

FWIW, at no extra cost, I went to the trouble of testing it on some
flavour of Linux with Python 2.6 and got the same results
as per 2.2.2 on WinXP. (Basically: everything works).

Which leaves us with http://bugs.python.org/issue8036 in which recent
versions of Python crash when the (arbitrary) second parameter isn't
passed. And with an inexplicable behaviour change between the same
version of Python running on WinXP and on Win7.

OP reports 2.6 with XP works. Did that use VS 2005? Maybe C runtime
changed (regressed). Also, could there be a 32 v. 64 bit issue?

 

[Terry Reedy]

FWIW, although it's not obvious, the args parameter to spawnl
is intended to become the sys.args (in Python terms) of the
newly-spawned process. Which is why the first element is expected
to be the name of the process. It took me some time to realise
this myself

Anyway, glad we could be of help.

Can we make this fix automatic for Win7 to fix #8036?

 

[Tim Golden]

Can we make this fix automatic for Win7 to fix #8036?

It's tempting, but I think not. In principle, the caller can
pass any value as the first arg of spawn: it'll simply end up
as sys.argv[0] in Python terms. If spawnl were the way of the
future, I'd be inclined to argue for the change. As it it, though,
I'd simply apply the patch and, possibly, add a line to the docs
indicating that the args must be non-empty.

(I started to import the patch yesterday but something got in the
way; I'll see if I can get it done today).

TJG