patch = fork on its own stops measuring forked child processes

Abierto
  • ¿Algo no está bien?
#2,340 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

@SwastikTripathi ya está trabajando en esto.

Desde el 22/10/2026.

  • #2342 de @SwastikTripathi — abierto

Evaluación

Dificultad
3/5
Tiempo estimado
1-2 días
Aptitud para principiantes
35/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Estancado
Stack tecnológico
python
Área
testing-qa

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.
Lenguaje dominante
Python
Estrellas
3.4k
Forks
554
Merge medio
1 d 10 h
PR fusionados (30 d)
13

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de coveragepy/coveragepy

Todos los issues de coveragepy/coveragepy

Issues similares

Más issues de Python

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.