Hacktoberfest 2026:维护者为十月标记出来的 issue,仍然开放、适合新手。 浏览 Hacktoberfest issue

Parallel mode: 'No status file found' INTERNAL ERROR when loading a plugin holds the GIL for more than 3 s

未关闭
#22,024 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

还没有人认领这个 Issue。

评估

难度
4/5
预计耗时
3-5 天
新手友好度
48/100
Issue 类型
缺陷
描述清晰度
基本清楚
活跃度
活跃
技术栈
python
领域
tooling

调研方向

Start with mypy/build.py, especially WorkerClient.connect(), build(), and build_inner(), then run the supplied ctypes plugin reproduction with -n 2. Trace the coordinator’s status-file deadline and the worker connection timeout; done means the slow-plugin case no longer produces the reported INTERNAL ERROR or loses an already-written status file.

由索引模型根据 Issue 内容生成。

描述

crash parallel checking

Crash Report

With -n 2, mypy fails with "Failed to establish connection with worker: No status file found" although both workers started and wrote their status files in time. build() starts the workers and their connect() threads before build_inner() loads plugins. If a plugin import holds the GIL past the 3 s WORKER_START_TIMEOUT, the threads cannot poll, and when they next run the loop has timed out and exits without reading the status file again.

We hit this in PyVista, whose plugin imports VTK, on the first run in a new environment. On macOS the first dlopen() of a newly installed binary waits for an XProtect scan while holding the GIL, so that import blocks for 12 to 17 s (0.12 s afterwards). In one failing run the workers wrote their status files 1.2 s after spawn, and the coordinator was still in the plugin import 12 s later.

Reading the status file once more after the deadline fixes the ctypes reproduction below (tested on master):

--- a/mypy/build.py
+++ b/mypy/build.py
@@ -289,11 +289,13 @@ class WorkerClient:
     def connect(self) -> None:
         end_time = time.time() + WORKER_START_TIMEOUT
         last_exception: Exception | None = None
-        while time.time() < end_time:
+        while True:
             try:
                 data = read_status(self.status_file)
             except BadStatus as exc:
                 last_exception = exc
+                if time.time() >= end_time:
+                    break
                 time.sleep(WORKER_START_INTERVAL)
                 continue
             try:

It does not reliably fix the VTK case: when the stall outlasts the worker's own 10 s WORKER_CONNECTION_TIMEOUT, the worker has stopped waiting and the run fails with Failed to establish connection with worker: [Errno 2] No such file or directory instead. Starting the workers after plugins are loaded may avoid both. It would also help to report this as an ordinary error rather than an INTERNAL ERROR. #21969 and #21974 look similar but have different causes.

Traceback

error: INTERNAL ERROR -- Please try using mypy master on GitHub:
https://mypy.readthedocs.io/en/stable/common_issues.html#using-a-development-mypy-build
Please report a bug at https://github.com/python/mypy/issues
version: 2.3.1
note: use --pdb to drop into pdb
Failed to establish connection with worker: No status file found
Failed to establish connection with worker: No status file found
Traceback (most recent call last):
  File ".../venv/lib/python3.14/site-packages/mypy/__main__.py", line 16, in console_entry
    main()
    ~~~~^^
  File "mypy/main.py", line 154, in main
  File "mypy/main.py", line 244, in run_build
  File "mypy/build.py", line 422, in build
  File "mypy/build.py", line 537, in build_inner
  File "mypy/build.py", line 4145, in dispatch
OSError: Cannot connect to build worker(s): 0, 1

To Reproduce

A plugin that holds the GIL for 4 s. This fails on every run, with 2.3.1 and with master; sleep(2) passes.

mkdir pkg && echo 'x: int = 1' > pkg/__init__.py
cat > gil_plugin.py <<'EOF'
import ctypes

from mypy.plugin import Plugin

# Hold the GIL for 4 s, as a slow import of a compiled extension can.
ctypes.PyDLL(None).sleep(4)


def plugin(version: str) -> type[Plugin]:
    return Plugin
EOF
printf '[mypy]\nplugins = gil_plugin.py\n' > mypy.ini
mypy -n 2 --show-traceback pkg

On macOS, import vtkmodules.vtkRenderingCore in place of the ctypes lines, in a new venv with mypy==2.3.1 vtk==9.7.0, fails on the first run and passes on the second. Precompiling bytecode (UV_COMPILE_BYTECODE=1) makes no difference.

Your Environment

  • Mypy version used: 2.3.1 (compiled: yes), and master at b645e069c (from git, not compiled)
  • Mypy command-line flags: -n 2 --show-traceback
  • Mypy configuration options from mypy.ini (and other config files): plugins = gil_plugin.py
  • Python version used: 3.14.0 and 3.14.5
  • Operating system and version: macOS 26.6.2, arm64 (the ctypes reproduction should not be macOS-specific, but I only ran it there)

Investigated and drafted with Claude Code (Claude Opus 5.5).

主要语言
Python
星标
20.6k
派生
3.3k
平均合并
1 天 12 小时
30 天内合并 PR
58

贡献指南

打开贡献指南

从这里开始

  1. 先读完整个 Issue,再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库,在一个分支上完成修改。
  4. 提交 Pull Request,并在描述里引用这个 Issue 编号。

python/mypy 的其他 Issue

查看 python/mypy 的全部 Issue

相似的 Issue

更多 Python Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。