http://buildbot.python.org/all/builders/x86%20Windows7%203.x/builds/601/steps/test/logs/stdio

======================================================================
FAIL: test_mymanager_context (test.test_multiprocessing_spawn.WithManagerTestMyManager)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\_test_multiprocessing.py", line 2232, in test_mymanager_context
    self.assertEqual(manager._process.exitcode, 0)
AssertionError: -15 != 0

----------------------------------------------------------------------
Ran 277 tests in 667.577s

FAILED (failures=1, skipped=24)
test test_multiprocessing_spawn failed

> manager._process.exitcode == -15

-15 is -signal.SIGTERM and comes from Popen.wait() of multiprocessing.popen_spawn_win32.

            res = _winapi.WaitForSingleObject(int(self._handle), msecs)
            if res == _winapi.WAIT_OBJECT_0:
                code = _winapi.GetExitCodeProcess(self._handle)
                if code == TERMINATE:
                    code = -signal.SIGTERM

The process exited and its exit code is 0x10000 (TERMINATE).

I understand that Popen.terminate() of multiprocessing.popen_spawn_win32 was called.

BaseManager.start() registers a finalizer: _finalize_manager(). This method sends a "shutdown" message to the process and then gives 1.0 second to the process to complete. If the process doesn't complete in 1 second, .terminate() is called.

1 second is kind of arbitrary: it depends on the system load. We should give more time to the manager to complete, or accept -signal.SIGTERM as a "valid" exit code.

I see different options:

* Shutdown the manager in test_multiprocessing and give more time to the manager to complete
* Make the timeout configurable
* Allow -signal.SIGTERM exit code in test_mymanager_context()

Similar issue: bpo-31510.

The bug can easily be reproduced on Linux using this change:

diff --git a/Lib/multiprocessing/managers.py b/Lib/multiprocessing/managers.py
index 04df26bac6..3d952407c2 100644
--- a/Lib/multiprocessing/managers.py
+++ b/Lib/multiprocessing/managers.py
@@ -649,7 +649,7 @@ class BaseManager(object):
             except Exception:
                 pass
 
-            process.join(timeout=1.0)
+            process.join(timeout=0.0)
             if process.is_alive():
                 util.info('manager still alive')
                 if hasattr(process, 'terminate'):

Python 2.7 terminates the manager process if it takes longer than 200 ms to stop (Python 3 uses a limit of 1 second), but test_multiprocessing doesn't test the exit code of the manager process and so Python 2.7 is not impacted by this bug.

> I see different options: (...) * Allow -signal.SIGTERM exit code in test_mymanager_context()

When I discussed with Davin, he told me that it's an acceptable solution.

So I wrote the PR 7968 to implement this trivial fix.

New changeset fbd7172325e6ce55b6d5d3d7603e4c1c8a219cb8 by Victor Stinner in branch 'master':
bpo-30356: Fix test_mymanager_context() of multiprocessing (GH-7968)
https://github.com/python/cpython/commit/fbd7172325e6ce55b6d5d3d7603e4c1c8a219cb8

New changeset 34f2935dca7bb20cd87e42dc41985cc3d688a735 by Miss Islington (bot) in branch '3.7':
bpo-30356: Fix test_mymanager_context() of multiprocessing (GH-7968)
https://github.com/python/cpython/commit/34f2935dca7bb20cd87e42dc41985cc3d688a735

New changeset a599323fc7661668a01e9fbb0d2369e62941bdf1 by Miss Islington (bot) in branch '3.6':
bpo-30356: Fix test_mymanager_context() of multiprocessing (GH-7968)
https://github.com/python/cpython/commit/a599323fc7661668a01e9fbb0d2369e62941bdf1

I fixed the test in 3.6, 3.7 and master branches.