Coveragepy: coverage.misc.CoverageException: Couldn't use data file '/path/to/.coverage': no such table: meta

Created on 7 Jan 2020  路  10Comments  路  Source: nedbat/coveragepy

Describe the bug
This bug bit me this morning when old TravisCI builds reported failing suddenly with no code changes in my library. https://travis-ci.org/mdshw5/pyfaidx/jobs/633813559#L1187.

To Reproduce
How can we reproduce the problem? Please be specific.

  1. What version of Python are you using?
    3.5-3.7. For some reason 3.4 does not exhibit this issue.
  2. What version of coverage.py are you using? The output of coverage debug sys is helpful.
    I will try to figure this out.
  3. What versions of what packages do you have installed? The output of pip freeze is helpful.
  4. What code are you running? Give us a specific commit of a specific repo that we can check out.
    https://travis-ci.org/mdshw5/pyfaidx/jobs/633813559#L998
  5. What commands did you run?
    nosetests --with-coverage --cover-package=pyfaidx
    Expected behavior
    A clear and concise description of what you expected to happen.
    I expected coverage to be computed instead of a runtime error.
    Additional context
    I'll gladly provide more context where I can - I'm still reasoning about how to reproduce a Travis build locally.
bug fixed

All 10 comments

This is seemingly related to #915, and discussion should continue here.

Thanks, I can try to reproduce this, though it looks like you have some tricky things to install. The more detailed you can make the instructions, the higher my success rate.

PS: You should come to Boston Python! :)

Thanks @nedbat. I'll work on a minimal reproducible example tonight when I have time. I do see that my builds that were previously passing were using coverage-4.5.4, and the same commit that now fails when triggered manually (or by a cron job in this case) is using coverage-5.0.2. A diff of the logs shows that very little has changed other than the coverage version and the numpy version. For right now I'm going to pin my coverage version at 4.5.4, and can try to update with more info you might need to reproduce this.

$ diff <(curl https://api.travis-ci.org/v3/job/623223954/log.txt) <(curl https://api.travis-ci.org/v3/job/633813559/log.txt)

Here is the result in diff format

@mdshw5 I've reproduced the problem with your repo. A fix will happen soon, thanks.

@mdshw5 You can pin to 5.0.1, it works fine.

Thanks @nedbat. I've actually been to Boston Python once in the past, about 5 years ago, and have been meaning to start going for some time. Seems like a great group, and now that my kids are a bit older, and I can stay in the city a bit later after work (I commute from a north shore suburb) I'll make more of an effort to show up :).

This is fixed in e4b8389b27ce4e7681788b8a28dc875ff4991739

I'll unpin the version of coverage in my module and mention this issue to confirm the fix works for me.

@nedbat Thanks for pushing changes to fix this issue. I can confirm that the current master fixes the problem for me, and I look forward to a 5.0.3 release on PyPI!

This is now available in 5.0.3: https://pypi.org/project/coverage/5.0.3/

Was this page helpful?
0 / 5 - 0 ratings