Multiple use of combine leads to empty .coverage

[nedbat]

Originally reported by Anonymous

---

The full issue we had is reported here on Github (I am @alalazo, in case you want to drop a message there).

Briefly, our program spawn subprocesses and the code therein is tested with the concurrency=multiprocessing parallel=True option of coverage run. Due to a problem yet to identify, very likely on our side, a few of the .coverage.* files generated are empty.

If we recombine the data we have errors like:

#!console

$ coverage combine
Coverage.py warning: Couldn't read data from '/home/travis/build/spack/spack/.coverage.travis-job-spack-spack-323456025.travisci.net.9618.332776': CoverageException: Doesn't seem to be a coverage.py data file
Coverage.py warning: Couldn't read data from '/home/travis/build/spack/spack/.coverage.travis-job-spack-spack-323456025.travisci.net.9686.644486': CoverageException: Doesn't seem to be a coverage.py data file
Coverage.py warning: Couldn't read data from '/home/travis/build/spack/spack/.coverage.travis-job-spack-spack-323456025.travisci.net.9719.277474': CoverageException: Doesn't seem to be a coverage.py data file

but nonetheless we obtain a .coverage file which is the merge of the other hundreds of well formed files. In the case above the three empty files are left in the directory.

At this point if we re-run:

#!console

$ coverage combine
Coverage.py warning: Couldn't read data from '/home/travis/build/spack/spack/.coverage.travis-job-spack-spack-323456025.travisci.net.9618.332776': CoverageException: Doesn't seem to be a coverage.py data file
Coverage.py warning: Couldn't read data from '/home/travis/build/spack/spack/.coverage.travis-job-spack-spack-323456025.travisci.net.9686.644486': CoverageException: Doesn't seem to be a coverage.py data file
Coverage.py warning: Couldn't read data from '/home/travis/build/spack/spack/.coverage.travis-job-spack-spack-323456025.travisci.net.9719.277474': CoverageException: Doesn't seem to be a coverage.py data file

the .coverage file gets rewritten using only the empty files, and all the data get lost.

If you consider this to be an issue, I can try to look into putting together a PR to fix this (maybe checking upfront in combine if a .coverage file is already in the current directory). What do you think?

---

• Bitbucket: https://bitbucket.org/ned/coveragepy/issue/629

[nedbat]

Can you provide a simple reproducible case? Even if it's "run coverage with parallel, then create a fake empty data file, then run combine twice" or whatever?

[nedbat]

From the GitHub issue: to reproduce:

$ cat > foo.py
print("hi")
$ coverage run foo.py
hi
$ cat .coverage
!coverage.py: This is a private format, don't read it directly!{"lines":{"/private/tmp/foo.py":[1]}}
$ touch .coverage.1
$ coverage combine
Coverage.py warning: Couldn't read data from '/private/tmp/.coverage.1': CoverageException: Doesn't seem to be a coverage.py data file
$ cat .coverage
!coverage.py: This is a private format, don't read it directly!{}

"coverage combine" deletes the .coverage file and makes a new one from the combinable files. If a file can't be read, it is left in place instead of being deleted.

BTW, "coverage combine -a" would append to the .coverage file instead of replacing it.

[nedbat]

Fixed in aff7c4ca5085 (bb)

Now if combine can't read any of the files it found, it will raise an error.

[nedbat]

This was included in coverage.py v4.5, released today.