Child process running as debug on Windows

[thebits]

BPO	12098
Nosy	@amauryfa, @pitrou, @kristjanvalur, @vstinner, @tiran, @bitdancer
Files	Issue12098.branch-2.6.patch Issue12098.branch-default.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 = None
closed_at = <Date 2013-03-22.17:26:40.809>
created_at = <Date 2011-05-17.20:38:52.751>
labels = ['interpreter-core', 'type-feature', 'library', 'OS-windows']
title = 'Child process running as debug on Windows'
updated_at = <Date 2013-03-22.17:26:40.808>
user = 'https://bugs.python.org/thebits'

bugs.python.org fields:

activity = <Date 2013-03-22.17:26:40.808>
actor = 'kristjan.jonsson'
assignee = 'none'
closed = True
closed_date = <Date 2013-03-22.17:26:40.809>
closer = 'kristjan.jonsson'
components = ['Interpreter Core', 'Library (Lib)', 'Windows']
creation = <Date 2011-05-17.20:38:52.751>
creator = 'thebits'
dependencies = []
files = ['22041', '22042']
hgrepos = []
issue_num = 12098
keywords = ['patch']
message_count = 23.0
messages = ['136178', '136179', '136181', '136182', '136185', '136239', '136241', '136245', '136387', '136399', '136863', '160623', '160641', '161056', '161058', '161059', '161062', '161063', '184638', '184690', '184697', '184712', '184715']
nosy_count = 11.0
nosy_names = ['amaury.forgeotdarc', 'pitrou', 'kristjan.jonsson', 'vstinner', 'christian.heimes', 'jnoller', 'r.david.murray', 'neologix', 'python-dev', 'sbt', 'thebits']
pr_nums = []
priority = 'normal'
resolution = 'fixed'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue12098'
versions = ['Python 2.7', 'Python 3.3']

[thebits]

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!

[vstinner]

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)

[thebits]

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
"""

[neologix]

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.

[amauryfa]

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.

[vstinner]

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.

[pitrou]

We already have some logic for that:
http://hg.python.org/cpython/file/default/Lib/test/support.py#l1398

[thebits]

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.

[pitrou]

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.

[thebits]

I updated the patch.
Added a test and remove arguments for frozen interpreter.

[pitrou]

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.

[sbt]

• 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?

[pitrou]

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 bpo-1816, long after the -u flag itself. The code to reflect "-u" is commented out, perhaps Christian Heimes can shed some light on this.

[python-dev]

New changeset 347735ec92eb by Richard Oudkerk in branch 'default':
bpo-12098: Make multiprocessing's child processes inherit sys.flags on Windows
http://hg.python.org/cpython/rev/347735ec92eb

[sbt]

> 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.

[pitrou]

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.

[pitrou]

> 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.

[python-dev]

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

[kristjanvalur]

Reopening this since this it needs backporting to 2.7

[python-dev]

New changeset 37f52e71f4cd by Kristján Valur Jónsson in branch '2.7':
Issue bpo-12098: multiprocessing on Windows now starts child processes
http://hg.python.org/cpython/rev/37f52e71f4cd

[bitdancer]

Early indications are that this backport broke test running on the buildbots:

http://buildbot.python.org/all/builders/AMD64%20OpenIndiana%202.7/builds/1614

[kristjanvalur]

The buildbots page has been down for a while now, I can't see what's going on.

[python-dev]

New changeset b0b507268d7c by Kristján Valur Jónsson in branch '2.7':
Issue bpo-12098 : Fix a missing import in the unittests.
http://hg.python.org/cpython/rev/b0b507268d7c