coverage.py can't trace child processes of a fork()

[nedbat]

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

---

I wanted to get code coverage for tests of a project that makes heavy use of python 2.6 multiprocessing, and discovered I wasn't getting any coverage data for the child processes, though they were obviously running. This is even with the -p option.

I distilled it down to a simple test case that called os.fork() and ran a few lines of code in the child. (will attach).

I then discovered that the problem is that in parallel mode, the filename (including pid) is decided when the CollectorData object is created, rather than saved.

When one postpones creating the filename suffix until save() time, as the to-be-attached patch does, it works beautifully for fork() as far as I can tell in initial testing.

The attached patch should only change behavior when the suffix is due to parallel=True, not when an explicit suffix is given.

Of course, the fork()'d processes will have duplicate coverage data from their parents. But as long as coverage.py only tracks whether or not a line of code was run or branch taken, not how many times, this duplication is a non-issue, as the results from combine will be what is desired.

I haven't done extensive testing yet, and couldn't find a test suite for coverage.py? But thus far it's working for me.

Comments?

---

• Bitbucket: https://bitbucket.org/ned/coveragepy/issue/56
• This issue had attachments: testcover.py, coverage-3.3.1-fork.patch. See the original issue for details.

[nedbat]

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

---

coverage-3.3.1-fork.patch is the patch to fix coverage.
testcover.py is the test case. Both with and without patch, do:

coverage run -p testcover.py
coverage combine
coverage report -m

and note the difference, in that with the patch the child shows coverage.

[nedbat]

Fixed in <<changeset d5659889f307 (bb)>>.

I didn't use the patch directly, but thanks for the contribution!