CI: Python 3.13 + Windows 上进程级崩溃（ACCESS_VIOLATION），已红 7 个月

[SongshGeo]

现象

Tests 3.13 on windows-latest 这个 CI job 持续失败至少 7 个月，而且是进程级崩溃，不是测试失败。

uv run pytest tests/ -vs --clean-alluredir --alluredir tmp/allure_results --cov=abses --no-cov-on-fail
make: *** [makefile:190: test-all] Error -1073741819
##[error]Process completed with exit code 1.

-1073741819 = 0xC0000005 = ACCESS_VIOLATION（Windows 段错误）。

关键证据：崩在 pytest 出任何输出之前

命令发出到崩溃只隔了 2.7 秒，中间 pytest 一行输出都没有 —— 没有 banner、没有 collected N items、没有任何测试结果：

18:42:02.6547022Z  uv run pytest tests/ -vs ...
18:42:05.3106552Z  make: *** [makefile:190: test-all] Error -1073741819
18:42:05.4418796Z  ##[error]Process completed with exit code 1.

说明崩溃发生在解释器启动 / 导入 / 收集阶段，任何一个测试都还没执行。所以这不是测试代码的问题，是运行时（多半是某个 C 扩展）的问题。

范围：精确锁定在 3.13 × Windows 的交集

	3.11	3.12	3.13
ubuntu-latest	✅	✅	✅
macos-latest	✅	✅	✅
windows-latest	✅	✅	❌ 崩溃

Windows 上 3.11/3.12 正常，3.13 在 Ubuntu/macOS 上也正常 —— 只有这一个格子坏。

持续时间

dev 上每一次 tests.yml 运行都是同一个 job 挂，回溯到能查到的最早记录：

run 32171945356  2026-08-18  Tests 3.13 on windows-latest
run 31798934357  2026-08-14  Tests 3.13 on windows-latest
run 24599874652  2026-04-18  Tests 3.13 on windows-latest
run 24087345337  2026-04-07  Tests 3.13 on windows-latest
run 21097630576  2026-01-17  Tests 3.13 on windows-latest
run 20794582936  2026-01-07  Tests 3.13 on windows-latest
run 20764084637  2026-01-06  Tests 3.13 on windows-latest

fail-fast: false，所以这不是被别的 job 连坐，是它自己稳定地崩。

为什么值得修

pyproject.toml 明确声称支持 3.13：

requires-python = ">=3.11,<3.14"
...
"Programming Language :: Python :: 3.13",

而 v0.11.7 已经发布到 PyPI。如果这个崩溃在 CI 之外也复现，那么Windows + Python 3.13 的用户装上 abses 后可能连 import 都会崩，而我们声称支持这个组合。

另外，长期红着的 CI 会让新的真实回归被淹没 —— 这次 #170 的审查里就得先花时间证明"这个红不是我引入的"。

建议排查路径

1. 先确认是不是纯 import 就崩（区分「abses 导入崩」和「pytest 插件崩」）。在 CI 里 pytest 之前加一步：

   - name: Import smoke test
     run: uv run python -c "import abses; print(abses.__version__)"

2. 打开 faulthandler 拿到 C 层栈，这是最能定位问题的一步：

   env:
     PYTHONFAULTHANDLER: 1

   或直接 uv run python -X faulthandler -m pytest ...。ACCESS_VIOLATION 目前是完全无声的，有了 faulthandler 才能看到崩在哪个扩展模块里。

3. 排除 pytest 插件：当前命令带了 --alluredir（allure-pytest）和 --cov（pytest-cov）。先用 uv run pytest tests/ -p no:cacheprovider --no-header -x 裸跑一次，看是否仍崩。

4. 对比 3.12 与 3.13 在 Windows 上解析出的轮子版本。uv.lock 会按 Python 版本给出不同的解析结果，嫌疑集中在自带原生库的那几个包：shapely、pyproj、rasterio、fiona、geopandas、numpy。Windows 上这几个各自打包 GEOS/PROJ/GDAL DLL，版本错配导致 import 期 DLL 冲突崩溃是常见故障模式。

   uv run python -c "import shapely, pyproj, rasterio; print(shapely.__version__, pyproj.__version__, rasterio.__version__)"
   

5. 如果短期定位不了，考虑临时把 3.13 × windows 从 matrix 里 exclude 掉并在 README/pyproject 里标注该组合暂不支持 —— 但这是权宜之计，且需要同步改 classifier，否则声称的支持与实际不符。

相关

• 在 fix(experiment): 🐛 Make num_process work under Hydra #170 的 CI 里首次被系统性地排查到（该 PR 与此无关，只是撞上了这个长期红灯）。