Issue #56 resolved 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 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 But thus far it's working for me.


Comments (2)

  1. jmalicki reporter

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

    coverage run -p coverage combine coverage report -m

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

  2. Log in to comment