Issue #545 invalid

Coverage fails on Python 3.6 Travis build

John Hagen
created an issue

I updated support one of my packages to test on Python 3.6 with Travis. For some reason only on Python 3.6 I am getting a failure and return code 120.

Coverage version: coverage-4.3.1.tar.gz

The build: https://travis-ci.org/johnthagen/cpplint-junit/jobs/187935844

The command used in the build:

python -Werror -Wignore::DeprecationWarning -m coverage run test.py

Tests under Python 2.7, 3.3, 3.4, and 3.5 all pass successfully.

Comments (5)

  1. Ned Batchelder repo owner

    I don't know where the 120 comes from, but it doesn't seem to be from coverage.py. I tried the command used by travis. It displayed a mysterious error about the enum module (?), and then the tests passed, and the exit status was 120:

    $ python -Werror -Wignore::DeprecationWarning -m coverage run test.py; echo Exited with $?
    'import warnings' failed; traceback:
    Traceback (most recent call last):
      File "/usr/local/virtualenvs/tmp-cd9a0f4d71ef3367/lib/python3.6/warnings.py", line 505, in <module>
        _processoptions(sys.warnoptions)
      File "/usr/local/virtualenvs/tmp-cd9a0f4d71ef3367/lib/python3.6/warnings.py", line 186, in _processoptions
        _setoption(arg)
      File "/usr/local/virtualenvs/tmp-cd9a0f4d71ef3367/lib/python3.6/warnings.py", line 192, in _setoption
        import re
      File "/usr/local/virtualenvs/tmp-cd9a0f4d71ef3367/lib/python3.6/re.py", line 122, in <module>
        import enum
    ModuleNotFoundError: No module named 'enum'
    ......
    ----------------------------------------------------------------------
    Ran 6 tests in 0.005s
    
    OK
    Exited with 120
    

    Then I tried removing the -W switches. No mysterious error, but still exit 120:

    $ python -m coverage run test.py; echo Exited with $?
    ......
    ----------------------------------------------------------------------
    Ran 6 tests in 0.005s
    
    OK
    Exited with 120
    

    Then I tried removing coverage from the command, and just running your test.py. It still exited with 120:

    $ python test.py; echo Exited with $?
    ......
    ----------------------------------------------------------------------
    Ran 6 tests in 0.003s
    
    OK
    Exited with 120
    

    I don't think this is about coverage.py

  2. Ned Batchelder repo owner

    The 3.6 docs for sys.exit say:

    Changed in version 3.6: If an error occurs in the cleanup after the Python interpreter has caught SystemExit (such as an error flushing buffered data in the standard streams), the exit status is changed to 120.

    I have no idea why that is happening in your program.

  3. John Hagen reporter

    The exit status 120 appears to be from this unit test:

    class ParseArgumentsTestCase(unittest.TestCase):
        def test_no_arguments(self):  # type: () -> None
            with self.assertRaises(SystemExit):
                # Suppress argparse stderr.
                class NullWriter:
                    def write(self, s):  # type: (str) -> None
                        pass
    
                sys.stderr = NullWriter()
                parse_arguments()
    

    Which is a crazy way I tried to test argparse input a while back. I removed it since it's really not of much value anyway and everything is fine now. Thanks for your help.

    I created an issue on the Python bug tracker to notify the core team, in case this particular effect was unintended: https://bugs.python.org/issue29130

  4. Log in to comment