patch = fork on its own stops measuring forked child processes

オープン
  • 何か問題がありますか？
#2,340 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

@SwastikTripathi がすでに取り組んでいます。

2026年10月22日 から。

  • #2342 @SwastikTripathi による — オープン

評価

難易度
3/5
見積もり時間
1〜2日
初心者へのやさしさ
35/100
issue の種類
バグ
明瞭さ
明確に書かれている
活発さ
停滞
技術スタック
python
領域
testing-qa

調査の方向性

The issue points to _after_fork_in_child() in coverage/control.py and reports behavior across the ctrace, pytrace, and sysmon cores. Start by reading that method and the described forky.py reproduction, then check the linked pull request #2342 for work already underway. Done means the child’s in_child() call is measured with patch = fork alone under all three cores.

索引モデルが issue の本文から書いたものです。

説明

Describe the bug

The docs say patch = fork "stops the previous coverage and starts a new one in the child process". The stop happens, but the restart goes through process_startup(), which only starts coverage when COVERAGE_PROCESS_CONFIG or COVERAGE_PROCESS_START is in the environment. Nothing puts either of them there unless patch = subprocess is also set, or the user sets COVERAGE_PROCESS_START by hand.

So with patch = fork on its own, measurement stops in the child and nothing restarts it. Code that only the child runs is reported as not run, with no warning. Without the patch, the same child is measured.

patch = fork was added in 7.10.4, and 7.10.4 and 7.16.2 behave the same. Current main (6033660c) does too, with each of the ctrace, pytrace and sysmon cores. I found it reading _after_fork_in_child() in control.py, not from a failing CI job.

To Reproduce

  1. Python 3.12.14 (macOS 15.7.3, arm64). I have not tried Linux.
  2. coverage 7.16.2 from PyPI. coverage debug sys (trimmed): coverage_version: 7.16.2, core: -none-, CTracer: available, implementation: CPython, platform: macOS-15.7.3-arm64-arm-64bit.
  3. pip freeze: coverage==7.16.2, nothing else.
  4. The code is forky.py below; no repo needed. It forks once, and only the child calls in_child().
  5. Commands, in an empty directory, with neither COVERAGE_PROCESS_START nor COVERAGE_PROCESS_CONFIG set. It makes a venv, writes forky.py, and runs it twice: once with patch = fork and once without, each in its own directory with parallel = true.
python3.12 -m venv .venv
.venv/bin/pip install coverage==7.16.2

cat > forky.py <<'PY'
import os

def in_child():
    a = 1
    return a

pid = os.fork()
if pid == 0:
    in_child()
else:
    os.waitpid(pid, 0)
PY

mkdir with_patch without_patch
cp forky.py with_patch/
cp forky.py without_patch/
printf '[run]\nparallel = true\npatch = fork\n' > with_patch/.coveragerc
printf '[run]\nparallel = true\n' > without_patch/.coveragerc

cd with_patch
../.venv/bin/coverage run forky.py
../.venv/bin/coverage combine
../.venv/bin/coverage report --show-missing
cd ../without_patch
../.venv/bin/coverage run forky.py
../.venv/bin/coverage combine
../.venv/bin/coverage report --show-missing

Output (pip lines left out):

Combined 2 files
Name       Stmts   Miss  Cover   Missing
----------------------------------------
forky.py       8      3    62%   4-5, 9
----------------------------------------
TOTAL          8      3    62%
Combined 2 files
Name       Stmts   Miss  Cover   Missing
----------------------------------------
forky.py       8      0   100%
----------------------------------------
TOTAL          8      0   100%

With the patch, lines 4-5 (the body of in_child(), which only the child runs) and line 9 (the call) are reported as missing.

Expected behavior

With patch = fork on its own, the child is measured again after the fork, so in_child() shows as covered, as it does without the patch.

Additional context

  • With patch = fork, subprocess the child is measured, because the subprocess patch puts the configuration in the environment. Even then, line 9 (the call, in the same frame as os.fork()) is missed: the new coverage starts partway through that frame, as with any start(). I have not tried to change that.
  • I have a small fix ready if you'd like a PR: in _after_fork_in_child(), when process_startup() finds nothing in the environment and a Coverage was running before the fork, start a new one with that Coverage's own configuration, using the same steps process_startup() uses. The environment path stays as it is, and a fork after stop() still starts nothing. It is +9/-1 in coverage/control.py, with tests that fail on main and pass with the change under all three cores. Happy to adjust it, or to drop it if you'd rather change the docs or handle this differently.
主要言語
Python
スター
3.4k
フォーク
554
平均マージ
1日 10時間
マージ済み PR（30日）
13

環境構築

このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

coveragepy/coveragepy のほかの issue

coveragepy/coveragepy の issue をすべて見る

似ている issue

Python の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。