Process can hang at exit: the non-daemon logistro stderr reader waits on a pipe that chrome_crashpad_handler (orphaned, macOS) still holds

未关闭
  • 哪里不对？
#319 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

还没有人认领这个 Issue。

评估

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

调研方向

Start by tracing how choreographer starts and closes the browser process and how logistro.getPipeLogger creates and manages its stderr reader; the issue identifies the reader thread as the point that keeps Python alive. Check whether logistro or choreographer owns that thread’s lifecycle, then reproduce the exit hang on macOS with the reported Chrome and package versions. Done means the reader cannot block interpreter exit while the browser’s stderr pipe remains open, with appropriate coverage for the chosen fix.

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

描述

Summary

After fig.to_image() (Kaleido 1.4.0, choreographer 1.4.0, logistro 2.0.1) has returned, the Python process can hang at exit. It stays at 0 % CPU in threading._shutdown, joining the browser_procThread reader that logistro.getPipeLogger("browser_proc") starts. That thread is not a daemon thread and is blocked in os.read on the browser's stderr pipe. It only returns at EOF, and EOF never comes while any process still holds the write end. On macOS, chrome_crashpad_handler holds it.

Environment

  • macOS
  • Python 3.13
  • kaleido 1.4.0, choreographer 1.4.0, logistro 2.0.1, plotly 7.1.0
  • System Chrome 156.0.8078.74 and 156.0.8078.80

What we measured

  • Who holds the pipe. When Chrome starts, a new chrome_crashpad_handler appears with PPID 1 and a session and process group of its own, so it double-forked with setsid. lsof shows its fd 2 as the other end of the logistro reader's pipe, in 5 of 5 runs. Its --database is the user's real Chrome profile (~/Library/Application Support/Google/Chrome/Crashpad), not the temporary --user-data-dir.
  • The handler outlives close(). Right after Browser.close() returns, the handler is still running; it usually exits about 1 to 1.5 s later. While it lives, the reader thread cannot end, and an interpreter that is exiting waits for it.
  • The cause, confirmed. We sent SIGSTOP to the handler after fig.to_image() returned. The process then hangs at exit, every time, and exits at once after SIGCONT.
  • Under real load. In a test suite with 12 concurrent processes, 2 of them passed their tests and then never exited. In the hung processes, sample shows the main thread in threading._shutdown joining two logistro pipe-reader threads blocked in os.read. 14 handlers had been orphaned at the time.
  • Other remedies don't reach it.
    • Killing the browser's process group doesn't reach the handler, because it has left that group and session.
    • --disable-breakpad, which choreographer already passes, doesn't stop macOS Chrome from starting the handler. We didn't test --disable-crash-reporter.
    • Linux and Windows were not measured.

Request

Make the reader thread a daemon thread: Thread(..., daemon=True) in logistro.getPipeLogger, or a way for choreographer to ask for one. A logging reader should not decide whether the interpreter can exit, and no process-group or tree walk can reach a process that has left the group.

A bounded join in Browser.close() would not help on its own. The thread stays non-daemon, so threading._shutdown still joins it at exit. It only helps together with a daemon thread, or with a reader that stops by itself, for example by polling the browser process between reads with a select timeout.

Which project should own the fix is your call, since the thread lives in logistro and choreographer is the consumer. Happy to provide more detail.

主要语言
Python
星标
17
派生
10
30 天内没有已合并 PR

环境准备

这个项目没有提供开发容器、Dockerfile 或贡献指南，环境需要你自己搭建：先看它的 README，通用步骤见我们的新手贡献指南。

从这里开始

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

plotly/choreographer 的其他 Issue

查看 plotly/choreographer 的全部 Issue

相似的 Issue

更多 Python Issue

把新 issue 发到你的邮箱

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