Attaching patch for both 3.4 and default/3.5 (single file works for both) which fixes the test to properly adjust for running under -Werror.


Whether -Werror is set or otherwise the equivalent of 'warnings.simplefilter("error", Warning)' has been set, any warnings will trigger messages being sent to stderr (that's good).  This problematic test, in particular, reassigns sys.stderr to point at a file in an attempt to capture exit codes from a Process into that file (that's okay); but any warning messages sent to stderr may also end up being captured inside that same file depending upon the timings of the threads involved (that's bad).  To support the established behavior inside multiprocessing for capturing non-int exit codes (see issue13854), the test has been made more robust to detect when it is being run with -Werror (or similar) and allow for extra messages potentially appearing on stderr, otherwise it will continue to use the existing test to validate the output seen on stderr (captured in that file).

In the suite of tests for multiprocessing, test_multiprocessing_spawn currently triggers a bunch of warnings due to differences in how spawn works versus fork -- one example of this common pattern:

    test_abort (test.test_multiprocessing_spawn.WithProcessesTestBarrier) ... Exception ignored in: <_io.FileIO name='/dev/null' mode='rb' closefd=True>
    ResourceWarning: unclosed file <_io.TextIOWrapper name='/dev/null' mode='r' encoding='UTF-8'>

How to better handle the triggering of these warnings in the first place is left as a topic for consideration in the future.


This patch's updated test has been tested with and without "-Werror" against 3.4 and default/3.5 on OS X 10.10.