Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
nedbat opened this issue Mar 15, 2010 · 2 comments
Closed

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

nedbat opened this issue Mar 15, 2010 · 2 comments
Labels
bug Something isn't working run

Comments

@nedbat
Copy link
Owner

nedbat commented Mar 15, 2010

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?


@nedbat
Copy link
Owner Author

nedbat commented Mar 15, 2010

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
Copy link
Owner Author

nedbat commented Mar 20, 2010

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

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working run
Projects
None yet
Development

No branches or pull requests

1 participant