Skip to content

CI: [diagnostic, do not merge] Test pytest --capture=no - #710

Closed
echoix wants to merge 1 commit into
mainfrom
ci-diag/no-capture-test
Closed

echoix wants to merge 1 commit into
mainfrom
ci-diag/no-capture-test

Conversation

@echoix

@echoix echoix commented Sep 26, 2026

Copy link
Copy Markdown
Owner

Purpose

Ninth diagnostic. Confirmed so far:

  • Plain `python -c` import: succeeds, before AND after the pip-install
    step (ci-diag/standalone-import-test,
    ci-diag/standalone-import-after-pip).
  • Bare `pytest`, `python -m pytest`, with or without `-n`/xdist: all
    crash identically with
    `Windows fatal exception: code 0xc0000139`
    (ci-diag/no-xdist-single-process, ci-diag/python-m-pytest-vs-exe).
  • pytest-timeout's watchdog thread (`pytest_runtest_protocol`) only
    wraps already-collected test items -- checked directly in its
    source, it does not start until after collection succeeds, and our
    crash happens during collection. Ruled out.
  • Every native dependency (GDAL, curl, OpenSSL, libjpeg-turbo, expat,
    PROJ, MSVCP140/msvcrt2019, the MSVC mutex-hack state) confirmed
    clean or unchanged via direct binary diffing across this whole
    investigation.

So the crash is specific to something pytest itself sets up before/
during collection that a plain python invocation never touches. The
one remaining big candidate: pytest's default fd-level output
capturing (`dup2`-based stdout/stderr redirection), active for the
entire session including collection, before any test file is even
imported -- a genuinely invasive, low-level OS handle manipulation
that Windows CRT/DLL initialization is known to sometimes interact
badly with.

What this PR does

Runs the same two known-failing test files with `--capture=no`
(disabling pytest's fd-level capture entirely), to see if that alone
avoids the crash.

This PR is for CI investigation only and is not meant to be merged.

🤖 Generated with Claude Code

…t for merge)

A plain `python -c "from grass.pygrass import utils"` succeeds even
after pip has installed pytest/xdist/timeout/randomly (see
ci-diag/standalone-import-after-pip), but pytest itself collecting the
same import crashes with "Windows fatal exception: code 0xc0000139"
regardless of xdist (ci-diag/no-xdist-single-process) or the exe
launcher stub (ci-diag/python-m-pytest-vs-exe). pytest-timeout's
watchdog thread (pytest_runtest_protocol) does not start until after a
test item is successfully collected, per its own source, so it isn't
running yet when this crash happens during collection -- ruling that
out too.

The other big process-wide difference between a plain python
invocation and a pytest run: pytest's default fd-level output
capturing (dup2-based stdout/stderr redirection), active for the
entire session including collection, before any test file is even
imported. This tests whether --capture=no (disabling it) avoids the
crash.

Temporary, for CI investigation only.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant