patch = fork on its own stops measuring forked child processes

Ouverte
  • Quelque chose ne va pas ?
#2,340 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

@SwastikTripathi y travaille déjà.

Depuis le 22/10/2026.

  • #2342 par @SwastikTripathi — ouverte

Évaluation

Difficulté
3/5
Temps estimé
1-2 jours
Accessibilité débutants
35/100
Type d'issue
Bug
Clarté
Clairement spécifiée
Activité
À l'abandon
Stack technique
python
Domaine
testing-qa

Piste de recherche

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.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

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.
Langage dominant
Python
Étoiles
3.4k
Forks
554
Merge moyen
1 j 10 h
PR mergées (30 j)
13

Préparer son environnement

Ce projet ne fournit ni conteneur de développement, ni Dockerfile, ni guide de contribution : l'installation est à votre charge. Commencez par son README, et consultez notre guide de la première contribution pour les étapes générales.

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de coveragepy/coveragepy

Toutes les issues de coveragepy/coveragepy

Issues similaires

Plus d'issues Python

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.