Copying a Mock object breaks coverage

[nedbat]

Originally reported by n1ywb (Bitbucket: n1ywb, GitHub: n1ywb)

---

There's a strange trifecta of misbehavior occurring when I copy a Mock object. Following the copy, coverage seems to no longer be able to keep track of coverage. I've attached a trivial program that reproduces the bug. easy_install mock if you don't already have it.

It's possible the root cause is in Mock or some weird interaction between Mock and copy. But unless they're doing something very unholy, it seems like it should not break coverage.

Neither --timid nor --branch helps.

I just checked the latest thing out from bitbucket,

changeset: 932:8990640eecd9
tag: tip
user: Ned Batchelder [email protected]
date: Sun Oct 03 13:21:17 2010 -0400
summary: A better way to figure out that the version number has a letter in it.

I chucked trace.c since I didn't have a compiler installed.

Coverage.py, version 3.5a1. http://nedbatchelder.com/code/coverage/3.5a1

Python 2.5.4

For what it's worth I also see this bug with the ancient version of coverage that comes with Eclipse PyDev.

jlaughlin@jlaughlin ~/tmp/coverage_bug
$ coverage run --timid test_bug.py -v && coverage report -m
copied a mock
I was called!
test_copy_mock (__main__.Test_1_copy_mock) ... ok
test_a_trivial_function (__main__.Test_2_a_trivial_function) ... ok

----------------------------------------------------------------------
Ran 2 tests in 0.017s

OK
Name       Stmts   Miss  Cover   Missing
----------------------------------------
test_bug      14      3    79%   7, 12, 16

If you comment out line 11 in the program that copies the mock, coverage jumps to 100%.

---

• Bitbucket: https://bitbucket.org/ned/coveragepy/issue/93
• This issue had attachments: test_bug.py, output_bug, output_no_bug, test_bug.py, test_bug.py. See the original issue for details.

[nedbat]

Original comment by n1ywb (Bitbucket: n1ywb, GitHub: n1ywb)

---

Here's an even smaller program that triggers the bug without using unittest.

[nedbat]

Original comment by n1ywb (Bitbucket: n1ywb, GitHub: n1ywb)

---

I opened a ticket in the Mock project as well: http://code.google.com/p/mock/issues/detail?id=48

[nedbat]

This is due to an infinite recursion in Mock.getattr. I've put a fix on the Mock ticket.

When the infinite recursion happens, the trace function doesn't get any indication of the stack unwinding through the 995 levels of infiniteness.

I'll leave this open to see if there's something we can do in coverage.py to at least indicate that something pathological is going on.

[nedbat]

Marius Gedminas had a good idea: "You could look at sys.gettrace() at the end: if it still points to your trace function, everything's probably fine, but if it got reset to None, warn the user." (http://nedbatchelder.com/blog/201010/surprising_getattr_recursion.html#comments)

[nedbat]

Changeset <<changeset faac189e0e45 (bb)>> adds Marius' warning idea. That's as good as I'm going to be able to make it.