Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #14916 > unrolled thread

spawnl issues with Win 7 access rights

Back to article view | Back to comp.lang.python

Contents

  spawnl issues with Win 7 access rights Propad <npropadovic@googlemail.com> - 2011-10-24 05:43 -0700
    Re: spawnl issues with Win 7 access rights Tim Golden <mail@timgolden.me.uk> - 2011-10-24 14:18 +0100
      Re: spawnl issues with Win 7 access rights Propad <npropadovic@googlemail.com> - 2011-10-24 06:47 -0700
        Re: spawnl issues with Win 7 access rights Terry Reedy <tjreedy@udel.edu> - 2011-10-24 18:16 -0400
    Re: spawnl issues with Win 7 access rights Tim Golden <mail@timgolden.me.uk> - 2011-10-24 15:18 +0100
    Re: spawnl issues with Win 7 access rights Terry Reedy <tjreedy@udel.edu> - 2011-10-24 18:14 -0400
    Re: spawnl issues with Win 7 access rights Miki Tebeka <miki.tebeka@gmail.com> - 2011-10-24 17:21 -0700
      Re: spawnl issues with Win 7 access rights Propad <npropadovic@googlemail.com> - 2011-10-25 00:01 -0700
        Re: spawnl issues with Win 7 access rights Tim Golden <mail@timgolden.me.uk> - 2011-10-25 13:19 +0100
        Re: spawnl issues with Win 7 access rights Terry Reedy <tjreedy@udel.edu> - 2011-10-25 21:11 -0400
        Re: spawnl issues with Win 7 access rights Tim Golden <mail@timgolden.me.uk> - 2011-10-26 15:38 +0100
        Re: spawnl issues with Win 7 access rights Terry Reedy <tjreedy@udel.edu> - 2011-10-26 15:20 -0400
          Re: spawnl issues with Win 7 access rights Propad <npropadovic@googlemail.com> - 2011-10-27 03:27 -0700
            Re: spawnl issues with Win 7 access rights Tim Golden <mail@timgolden.me.uk> - 2011-10-27 11:36 +0100
            Re: spawnl issues with Win 7 access rights Terry Reedy <tjreedy@udel.edu> - 2011-10-27 15:53 -0400
            Re: spawnl issues with Win 7 access rights Tim Golden <mail@timgolden.me.uk> - 2011-10-28 09:22 +0100

#14916 — spawnl issues with Win 7 access rights

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

[toc] | [next] | [standalone]

#14917

On 24/10/2011 13:43, Propad wrote:
> 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

[toc] | [prev] | [next] | [standalone]

#14919

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

On 24 Okt., 15:18, Tim Golden <m...@timgolden.me.uk> wrote:
> On 24/10/2011 13:43, Propad wrote:
>
>
>
>
>
> > 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 -

[toc] | [prev] | [next] | [standalone]

#14941

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.

-- 
Terry Jan Reedy

[toc] | [prev] | [next] | [standalone]

#14920

On 24/10/2011 14:18, Tim Golden wrote:
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.

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

[toc] | [prev] | [next] | [standalone]

#14940

On 10/24/2011 10:18 AM, Tim Golden wrote:
> On 24/10/2011 14:18, Tim Golden wrote:
> 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.

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 Jan Reedy

[toc] | [prev] | [next] | [standalone]

#14942

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

[toc] | [prev] | [next] | [standalone]

#14950

On 25 Okt., 02:21, Miki Tebeka <miki.teb...@gmail.com> wrote:
> 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

[toc] | [prev] | [next] | [standalone]

#14963

On 25/10/2011 08:01, Propad wrote:
> 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%28v=vs.80%29.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

[toc] | [prev] | [next] | [standalone]

#14991

On 10/25/2011 8:19 AM, Tim Golden wrote:
> On 25/10/2011 08:01, Propad wrote:
>> 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%28v=vs.80%29.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 Jan Reedy

[toc] | [prev] | [next] | [standalone]

#15002

On 26/10/2011 02:11, Terry Reedy wrote:
> OP reports 2.6 with XP works.

Where do you see that, Terry? (Or was there an offlist email?)

> Did that use VS 2005? Maybe C runtime
> changed (regressed).

That's possible -- and is essentially my main guess (faute de mieux). 
I've got the same results on 32 & 64-bit machines.

Hopefully the workaround I suggested -- doubling up the executable 
filepath -- will get round the user's particular issue. I'm not going to 
fight CRT changes, but if no-one else gets there, I will try to address 
issue8036

TJG

[toc] | [prev] | [next] | [standalone]

#15009

On 10/26/2011 10:38 AM, Tim Golden wrote:
> On 26/10/2011 02:11, Terry Reedy wrote:
>> OP reports 2.6 with XP works.
>
> Where do you see that, Terry? (Or was there an offlist email?)

The first message of http://bugs.python.org/issue8036
"Python 2.6 is however happy and just reports invalid arg."

-- 
Terry Jan Reedy

[toc] | [prev] | [next] | [standalone]

#15035

Hello Gentelmen,

the suggestion to add the optional second parameter fixed the problem,
spawnl now works on the Win 7 computer I'm responsible for (with
Python 2.2). So the suggested cause seems to be right.

Thank you for the great help!

Cheers,

Nenad



On 26 Okt., 21:20, Terry Reedy <tjre...@udel.edu> wrote:
> On 10/26/2011 10:38 AM, Tim Golden wrote:
>
> > On 26/10/2011 02:11, Terry Reedy wrote:
> >> OP reports 2.6 with XP works.
>
> > Where do you see that, Terry? (Or was there an offlist email?)
>
> The first message ofhttp://bugs.python.org/issue8036
> "Python 2.6 is however happy and just reports invalid arg."
>
> --
> Terry Jan Reedy

[toc] | [prev] | [next] | [standalone]

#15036

On 27/10/2011 11:27, Propad wrote:
> the suggestion to add the optional second parameter fixed the problem,
> spawnl now works on the Win 7 computer I'm responsible for (with
> Python 2.2). So the suggested cause seems to be right.

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.

TJG

[toc] | [prev] | [next] | [standalone]

#15056

On 10/27/2011 6:36 AM, Tim Golden wrote:
> On 27/10/2011 11:27, Propad wrote:
>> the suggestion to add the optional second parameter fixed the problem,
>> spawnl now works on the Win 7 computer I'm responsible for (with
>> Python 2.2). So the suggested cause seems to be right.
>
> 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?

-- 
Terry Jan Reedy

[toc] | [prev] | [next] | [standalone]

#15096

On 27/10/2011 20:53, Terry Reedy wrote:
> On 10/27/2011 6:36 AM, Tim Golden wrote:
>> On 27/10/2011 11:27, Propad wrote:
>>> the suggestion to add the optional second parameter fixed the problem,
>>> spawnl now works on the Win 7 computer I'm responsible for (with
>>> Python 2.2). So the suggested cause seems to be right.
>>
>> 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?
>

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

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web