search

nedbat / coveragepy

The code coverage tool for Python
https://coverage.readthedocs.io
Apache License 2.0
2.98k stars 427 forks source link

false negatives on pypy #240

Open nedbat opened 11 years ago

nedbat commented 11 years ago

Originally reported by Thomas Weißschuh (Bitbucket: t-8ch, GitHub: t-8ch)

We are facing unexplainable behaviour over at urllib3. After every run a subset of a certain number of lines is reported as uncovered. I have added print() statements before those lines. And indeed although my text is printed to the screen the the line is again reported as uncovered.

py26, py27, py32 and py33 work fine. Occurs with 3.6 and current default (c6743d8).

nedbat commented 8 years ago

@t-8ch Sorry i've let this sit for so long. Can we look into it again?

nedbat commented 11 years ago

Original comment by Thomas Weißschuh (Bitbucket: t-8ch, GitHub: t-8ch)

Yes they are. The tested code is executed in the main thread, the threads are join()-ed

nedbat commented 11 years ago

By any chance, are the tests that fail multi-threaded?

nedbat commented 11 years ago

Original comment by Thomas Weißschuh (Bitbucket: t-8ch, GitHub: t-8ch)

This is the first failed build: https://travis-ci.org/shazow/urllib3/jobs/5695998 The state of the tree of this build is here: https://github.com/shazow/urllib3/tree/384d14256b6aa8b4990c2aeb8c93e85fe75168cb

Running rm .coverage; tox -e pypy a few times will quickly show you the "hot spots" of mis-reported lines. Allo those line would be resonable to be uncovered (branches of an if-conditional, earlier conditional returns in the function) but they are definitely covered.

CPython also works if

[run]
timid = true

is specified in .coveragerc, so it shouldn't be the trace function.

nedbat commented 11 years ago

Can you provide more details? For example, the code that's being mis-reported?

ProsperousHeart commented 1 year ago

Since this is so stale, perhaps this is an issue to be closed?