Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

CI Intermittent `Windows fatal exception: access violation` in `tests/empirical_scope_observation.py`

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

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

まだ誰も着手していません。

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
22/100
issue の種類
バグ
明瞭さ
おおむね明確
活発さ
活発
技術スタック
github-actions, numpy, python
領域
testing-qa

調査の方向性

The crash is raised from blas_math in tests/empirical_scope_observation.py (line 58), run via continuous_integration/run_tests.sh with python -X faulthandler ... blas. Start by reading that test and the threadpoolctl code it drives, then try to reproduce on Windows with the failing environment. Done means identifying which native library faults, typically with a ProcDump capture and WinDbg analysis, or a fix that stops the intermittent access violation in CI.

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

説明

Partly generated by an agent, but I did double-check with my brain on 😉.

cc @itamarst in case you have some insights or you have seen something similar when putting this empirical tests together.

I may try to investigate further on my Windows VM to see if I can at least reproduce.

The problem

The Windows pylatest_conda_forge_openblas CI job intermittently crashes while running:

PYTHONPATH=. python -X faulthandler tests/empirical_scope_observation.py blas


+ python -X faulthandler tests/empirical_scope_observation.py blas
Windows fatal exception: access violation

Thread 0x00000f48 [ThreadPoolExecutor-0_0Windows fatal exception: ]access violation

 (most recent call first):

Current thread's C stack trace (most recent call first):
  <cannot get C stack on this system>
  File "D:\a\threadpoolctl\threadpoolctl\tests\empirical_scope_observation.py", line 58 in blas_math
  File "C:\Users\runneradmin\miniconda3\envs\testenv\Lib\concurrent\futures\thread.py", line 73 in run
  File "C:\Users\runneradmin\miniconda3\envs\testenv\Lib\concurrent\futures\thread.py", line 86 in run
  File "C:\Users\runneradmin\miniconda3\envs\testenv\Lib\concurrent\futures\thread.py", line 119 in _worker
  File "C:\Users\runneradmin\miniconda3\envs\testenv\Lib\threading.py", line 1024 in run
Windows fatal exception: access violation


Current thread's C stack trace (most recent call first):
  <cannot get C stack on this system>
./continuous_integration/run_tests.sh: line 34:  1491 Segmentation fault         PYTHONPATH=. python -X faulthandler tests/empirical_scope_observation.py blas
Error: Process completed with exit code 139.

Unfortunately, faulthandler doesn't show anything useful on Windows hence the cannot get C stack on this system

Environment

The September 24 failure and September 26 successful run both use:

  • Python 3.14.7, with the GIL enabled
  • NumPy 2.5.3
  • conda-forge OpenBLAS 0.3.34, pthreads build
  • The same threadpoolctl commit, f6bef5dca966327941a87f4a92673cd9c0096add
CI logs

It seems to happen quite often

To investigate further

It could be useful to capture a native crash dump with ProcDump and inspect it with WinDbg.

LLM suggestion

For this CI crash, use ProcDump to capture a dump, then inspect it with WinDbg. After downloading Microsoft ProcDump, run this in PowerShell with the conda environment activated and the repository as the working directory:

$env:PYTHONPATH = "."
New-Item -ItemType Directory -Force dumps | Out-Null

.\procdump64.exe -accepteula -ma -e 1 -f C0000005 -n 1 `
    -x dumps "$env:CONDA_PREFIX\python.exe" `
    -X faulthandler tests/empirical_scope_observation.py blas

This captures a full dump at the first access violation (C0000005), before application exception handlers run. Upload dumps/*.dmp as a CI artifact, using if: always() on the upload step. ProcDump options

Open the dump in WinDbg and run:

.symfix
.reload
!analyze -v
.ecxr
kv
~* kb

.ecxr selects the exception context; kv shows its native stack; ~* kb shows every thread’s stack.

Microsoft debugging guidance

Symbol availability determines the detail: without matching symbols, you may get DLL names and offsets rather than internal function names or source lines. Preserve the exact Python, NumPy and OpenBLAS binaries from the failing environment, plus any matching debug symbols. Even an unsymbolized trace can help establish which native library is crashing.

主要言語
Python
スター
434
フォーク
38
平均マージ
2日 9時間
マージ済み PR（30日）
7

環境構築

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

はじめの一歩

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

joblib/threadpoolctl のほかの issue

joblib/threadpoolctl の issue をすべて見る

似ている issue

Python の issue をもっと見る

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

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