classification
Title: Child process running as debug on Windows
Type: enhancement Stage: resolved
Components: Interpreter Core, Library (Lib), Windows Versions: Python 3.3, Python 2.7
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: Nosy List: amaury.forgeotdarc, christian.heimes, haypo, jnoller, kristjan.jonsson, neologix, pitrou, python-dev, r.david.murray, sbt, thebits
Priority: normal Keywords: patch

Created on 2011-05-17 20:38 by thebits, last changed 2013-03-22 17:26 by kristjan.jonsson. This issue is now closed.

Files
File name Uploaded Description Edit
Issue12098.branch-2.6.patch thebits, 2011-05-20 20:18 review
Issue12098.branch-default.patch thebits, 2011-05-20 20:19 review
Messages (23)
msg136178 - (view) Author: Sergey Mezentsev (thebits) Date: 2011-05-17 20:38
I run this code:
"""
from multiprocessing import Pool

def myfunc(x):
    assert False
    #if __debug__: print 'debug'
    return x - 1

if __name__ == '__main__':
    pool = Pool(processes=1)
    it = pool.imap(myfunc, xrange(5)) # or imap_unordered, map
    print it.next()

python -O myscript.py
"""

The myfunc() always raise AssertionError. But I run script with "-O" (optimization) command.

Interpreter is:
"""
Python 2.6.6 (r266:84297, Aug 24 2010, 18:46:32) [MSC v.1500 32 bit (Intel)] on win32
"""

Thanks!
msg136179 - (view) Author: STINNER Victor (haypo) * (Python committer) Date: 2011-05-17 20:52
I'm unable to reproduce this bug on Linux.

$ cat script.py
from multiprocessing import Pool
import os

def myfunc(x):
    import sys
    print("child", os.getpid(), "optimize?", sys.flags.optimize)
    assert False, "assert False"
    return x

if __name__ == '__main__':
    import sys
    print("parent optimize?", sys.flags.optimize)
    pool = Pool(processes=2)
    pool.map(myfunc, xrange(2)) # or imap_unordered, map

$ python -O script.py
('parent optimize?', 1)
('child', 30397, 'optimize?', 1)
('child', 30398, 'optimize?', 1)
msg136181 - (view) Author: Sergey Mezentsev (thebits) Date: 2011-05-17 21:02
In my system (Windows 7 (64) SP1, Python 2.6.6 32-bit) I have:
"""
d:\temp>python -O pool.py
('parent optimize?', 1)
('child', 4712, 'optimize?', 0)
(Traceback (most recent call last):
'  File "new.py", line 14, in <module>
chil    dpool.map(myfunc, xrange(2)) # or imap_unordered, map'
,   File "C:\Python26\lib\multiprocessing\pool.py", line 148, in map
4712, 'optimize    ?return self.map_async(func, iterable, chunksize).get()
'  File "C:\Python26\lib\multiprocessing\pool.py", line 422, in get
, 0)
    raise self._value
AssertionError: assert False
"""
msg136182 - (view) Author: Charles-François Natali (neologix) * (Python committer) Date: 2011-05-17 21:13
Under Linux, child processes are created with fork(), so they're run with the exact same environment as the parent process (among which sys.flags.optimize).
I don't know Windows at all, but since I've heard it doesn't have fork(), my guess is that the command-line is constructed before creating the child process, and maybe the -O command line argument is lost.
Just a guess.
msg136185 - (view) Author: Amaury Forgeot d'Arc (amaury.forgeotdarc) * (Python committer) Date: 2011-05-17 21:43
This happens only on Windows, where multiprocessing has to spawn a new intepreter; the -O parameter is certainly omitted.
Unix platforms fork() the current interpreter with all its state and don't have this issue.
msg136239 - (view) Author: STINNER Victor (haypo) * (Python committer) Date: 2011-05-18 12:39
I think that the problem is in Popen.get_command_line() of multiprocessing.forking.

There are other options changing Python behaviour: -b, -B, -E, -u, etc.
msg136241 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2011-05-18 13:03
We already have some logic for that:
http://hg.python.org/cpython/file/default/Lib/test/support.py#l1398
msg136245 - (view) Author: Sergey Mezentsev (thebits) Date: 2011-05-18 15:24
I create patch for Popen.get_command_line() ('2.6' and 'default' branches).

I don't know how to write the test. The sys.flags structure are read only.
msg136387 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2011-05-20 16:54
Thanks for the patches.
One comment: I'm not sure a frozen interpreter can take regular Python flags.
As for the test, you could run a function returning sys.flags from the child to the parent, and check that the returned value is equal to the parent's sys.flags.
msg136399 - (view) Author: Sergey Mezentsev (thebits) Date: 2011-05-20 20:23
I updated the patch.
Added a test and remove arguments for frozen interpreter.
msg136863 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2011-05-25 16:23
Ok, thanks for the patches. Some further comments:
- the function generating the flags should be exported (with a private name), so that it can be reused by Lib/test/[test_]support.py. Duplicate code is error-prone, especially when enumerating command-line flags, attribute names...
- in the tests, proc_flags() could simply return tuple(sys.flags). This is simpler and easier to maintain.
msg160623 - (view) Author: Richard Oudkerk (sbt) * (Python committer) Date: 2012-05-14 13:28
> - the function generating the flags should be exported (with a private 
> name), so that it can be reused by Lib/test/[test_]support.py. Duplicate 
> code is error-prone, especially when enumerating command-line flags, 
> attribute names...

Failure to build _multiprocessing will mean that multiprocessing cannot be imported.  So if the function goes somewhere in multiprocessing then it makes running the test suite with multiple processes dependent on the building of _multiprocessing.  Not sure if that is much of a problem since one can just run the test suite normally.

Also I don't think "-i" (inspect/interactive) should be passed on: a child process's stdin is os.devnull.

BTW, why isn't the use of "-u" (unbuffered stdout, stderr) reflected in sys.flags?
msg160641 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2012-05-14 17:20
> Failure to build _multiprocessing will mean that multiprocessing cannot 
> be imported.  So if the function goes somewhere in multiprocessing then 
> it makes running the test suite with multiple processes dependent on the 
> building of _multiprocessing.  Not sure if that is much of a problem
> since one can just run the test suite normally.

I don't think that's a problem indeed.

> Also I don't think "-i" (inspect/interactive) should be passed on: a 
> child process's stdin is os.devnull.

Ah, you're right.

> BTW, why isn't the use of "-u" (unbuffered stdout, stderr) reflected in 
> sys.flags?

Don't know. sys.flags was introduced in issue1816, long after the -u flag itself. The code to reflect "-u" is commented out, perhaps Christian Heimes can shed some light on this.
msg161056 - (view) Author: Roundup Robot (python-dev) Date: 2012-05-18 15:41
New changeset 347735ec92eb by Richard Oudkerk in branch 'default':
#12098: Make multiprocessing's child processes inherit sys.flags on Windows
http://hg.python.org/cpython/rev/347735ec92eb
msg161058 - (view) Author: Richard Oudkerk (sbt) * (Python committer) Date: 2012-05-18 16:02
> > Failure to build _multiprocessing will mean that multiprocessing cannot 
> > be imported.  So if the function goes somewhere in multiprocessing then 
> > it makes running the test suite with multiple processes dependent on the 
> > building of _multiprocessing.  Not sure if that is much of a problem
> > since one can just run the test suite normally.
> 
> I don't think that's a problem indeed.

Since multiprocessing also depends on threading, the change has broken the "AMD64 Fedora without threads 3.x" buildbot.  I had not realized that the buildbots ran the test suite using multiple processes.

I am not sure how best to refactor things -- I don't think multiprocessing should import test.support.  Maybe we should just live with the duplication.
msg161059 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2012-05-18 16:16
> Since multiprocessing also depends on threading, the change has broken
> the "AMD64 Fedora without threads 3.x" buildbot.  I had not realized
> that the buildbots ran the test suite using multiple processes.

They don't. It's only the import failing, so you should just catch and
ignore the ImportError.
msg161062 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2012-05-18 16:27
> > Since multiprocessing also depends on threading, the change has broken
> > the "AMD64 Fedora without threads 3.x" buildbot.  I had not realized
> > that the buildbots ran the test suite using multiple processes.
> 
> They don't. It's only the import failing, so you should just catch and
> ignore the ImportError.

Sorry, I have misread. It actually happens inconditionally in
run_tests.py, and is used to spawn the Python interpreter which will run
the test suite.
msg161063 - (view) Author: Roundup Robot (python-dev) Date: 2012-05-18 16:36
New changeset 2034b3de1144 by Antoine Pitrou in branch 'default':
Move private function _args_from_interpreter_flags() to subprocess.py, so
http://hg.python.org/cpython/rev/2034b3de1144
msg184638 - (view) Author: Kristján Valur Jónsson (kristjan.jonsson) * (Python committer) Date: 2013-03-19 15:15
Reopening this since this it needs backporting to 2.7
msg184690 - (view) Author: Roundup Robot (python-dev) Date: 2013-03-19 22:19
New changeset 37f52e71f4cd by Kristján Valur Jónsson in branch '2.7':
Issue #12098: multiprocessing on Windows now starts child processes
http://hg.python.org/cpython/rev/37f52e71f4cd
msg184697 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2013-03-19 22:43
Early indications are that this backport broke test running on the buildbots:

   http://buildbot.python.org/all/builders/AMD64%20OpenIndiana%202.7/builds/1614
msg184712 - (view) Author: Kristján Valur Jónsson (kristjan.jonsson) * (Python committer) Date: 2013-03-20 00:12
The buildbots page has been down for a while now, I can't see what's going on.
msg184715 - (view) Author: Roundup Robot (python-dev) Date: 2013-03-20 00:35
New changeset b0b507268d7c by Kristján Valur Jónsson in branch '2.7':
Issue #12098 : Fix a missing import in the unittests.
http://hg.python.org/cpython/rev/b0b507268d7c
History
Date User Action Args
2013-03-22 17:26:40kristjan.jonssonsetstatus: open -> closed
2013-03-20 00:35:21python-devsetmessages: + msg184715
2013-03-20 00:12:33kristjan.jonssonsetmessages: + msg184712
2013-03-19 22:43:50r.david.murraysetnosy: + r.david.murray
messages: + msg184697
2013-03-19 22:19:41python-devsetmessages: + msg184690
2013-03-19 15:15:08kristjan.jonssonsetstatus: closed -> open
versions: + Python 2.7
nosy: + kristjan.jonsson

messages: + msg184638
2012-05-25 12:13:36sbtsetstatus: open -> closed
resolution: fixed
stage: resolved
2012-05-18 16:36:02python-devsetmessages: + msg161063
2012-05-18 16:27:58pitrousetmessages: + msg161062
2012-05-18 16:16:02pitrousetmessages: + msg161059
2012-05-18 16:02:51sbtsetmessages: + msg161058
2012-05-18 15:41:13python-devsetnosy: + python-dev
messages: + msg161056
2012-05-14 17:20:41pitrousetnosy: + christian.heimes
messages: + msg160641
2012-05-14 13:28:37sbtsetmessages: + msg160623
2012-05-13 20:03:27pitrousetnosy: + sbt
2011-05-25 16:23:48pitrousetmessages: + msg136863
2011-05-20 20:23:25thebitssetmessages: + msg136399
2011-05-20 20:19:07thebitssetfiles: + Issue12098.branch-default.patch
2011-05-20 20:18:58thebitssetfiles: + Issue12098.branch-2.6.patch
2011-05-20 20:18:37thebitssetfiles: - Issue12098.branch-default.patch
2011-05-20 20:18:34thebitssetfiles: - Issue12098.branch-2.6.patch
2011-05-20 16:54:06pitrousetmessages: + msg136387
2011-05-18 15:24:37thebitssetfiles: + Issue12098.branch-default.patch
2011-05-18 15:24:29thebitssetfiles: + Issue12098.branch-2.6.patch
keywords: + patch
messages: + msg136245
2011-05-18 13:03:59pitrousetnosy: + pitrou
messages: + msg136241
2011-05-18 12:45:37amaury.forgeotdarcsetnosy: + jnoller
2011-05-18 12:39:30hayposetmessages: + msg136239
2011-05-17 21:43:02amaury.forgeotdarcsetnosy: + amaury.forgeotdarc
messages: + msg136185
2011-05-17 21:15:04pitrousettype: behavior -> enhancement
versions: + Python 3.3, - Python 2.6
2011-05-17 21:14:28hayposettitle: Child process running as debug -> Child process running as debug on Windows
2011-05-17 21:13:35neologixsetnosy: + neologix
messages: + msg136182
2011-05-17 21:02:49thebitssetmessages: + msg136181
2011-05-17 20:52:48hayposetnosy: + haypo
messages: + msg136179
2011-05-17 20:38:52thebitscreate