1. Ned Batchelder
  2. coverage.py
  3. Issues
Issue #56 resolved

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

created an issue

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 (2)

  1. Log in to comment