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

Mount is torn down while payload's child processes still map it: SIGBUS core dumps on app quit (Electron helpers)

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

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

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
48/100
issue の種類
バグ
明瞭さ
おおむね明確
活発さ
活発
技術スタック
c, linux
領域
operating-systems

調査の方向性

Start by tracing keepalive_pipe[0], write_pipe_thread(), and fuse_session_loop() in the runtime, then review how AppRun launches the payload. Reproduce the quit sequence with an Electron AppImage and inspect coredumpctl. Done means helper processes no longer receive SIGBUS and the mount remains usable until the last open or mapped reference is gone.

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

説明

Summary

When an Electron app packaged as an AppImage quits, its helper processes (zygote, renderer, utility, GPU, chrome_crashpad_handler) often die with SIGBUS (BUS_ADRERR), and systemd-coredump writes a core for each one. The helpers run from /tmp/.mount_*. The runtime unmounts as soon as the main process exits, but the helpers exit slightly later and still have files from the mount mapped. Once the FUSE daemon is gone, the next page fault on those mappings has no backing.

Environment

  • Omarchy (Arch Linux ARM), aarch64, kernel 7.1, fuse3 3.18.3
  • Beeper 4.3.152 (runtime https://github.com/AppImage/type2-runtime/commit/dd6cebe), T3 Code (older AppImageKit runtime effcebc), plus a third Electron app. All three behave the same.
  • The runtime logic involved is unchanged between dd6cebe and current main (8f39b89).

Steps

  1. Start an Electron AppImage normally.
  2. Quit it from its own UI or window close, or SIGTERM the main process.
  3. Run coredumpctl list.

Expected: no core dumps; the mount goes away once nothing uses it.
Actual: one or more SIGBUS cores per quit. 100 SIGBUS cores on this machine in about two weeks. Breakdown of the most recent 40 by process:

13 chrome_crashpad_handler
10 --type=zygote
 8 --type=renderer
 4 --type=utility
 4 app binary without --type
 1 --type=gpu-process

Example:

Signal: 7 (BUS) si_code: BUS_ADRERR
Command Line: /tmp/.mount_BeeperHpOEOh/chrome_crashpad_handler --monitor-self-annotation=ptype=crashpad-handler ...
Executable: /chrome_crashpad_handler

Cause

  • The runtime hands keepalive_pipe[0] to AppRun, meaning the app's main process.
  • Chromium launches its helpers with every non-mapped fd closed, so none of them holds the pipe.
  • When the main process exits, the last read end closes. write_pipe_thread() gets EPIPE (or SIGPIPE) and runs kill(fuse_pid, SIGTERM), and the FUSE daemon unmounts and exits.
  • The helpers are still shutting down at that moment; crashpad in particular outlives the browser by design. Any page they fault in from the mount now gets SIGBUS.

In other words, the mount's lifetime follows the main process instead of the last user of the filesystem. #131 and #138 change who waits on whom, but both still unmount when the top-level payload process exits, so I don't think they fix this case.

Suggested fix

When the keepalive breaks, detach the mount lazily instead of killing the daemon:

  • Call umount2(mountpoint, MNT_DETACH), or fusermount3 -u -z.
  • Keep fuse_session_loop() running. The kernel keeps the superblock alive while files are open or mapped and drops the connection once the last reference is gone. At that point the session loop returns and the daemon exits normally.

This also covers helpers that double-fork or reparent, which a "wait for children" approach would miss. An alternative is to make the waiting parent a subreaper (PR_SET_CHILD_SUBREAPER) and unmount only after all descendants have exited.

Related: orphaned runtime after the app relaunches itself

Seen with T3 Code's relaunch/self-update, which runs the older runtime but has the same keepalive code. The app re-executes its own AppImage. The new runtime, its FUSE daemon, and the new main process all inherit the old instance's keepalive_pipe[0] (it is not O_CLOEXEC, since it has to survive the exec into AppRun). The old daemon therefore never sees EPIPE. It stays resident with a mount that no process uses, while the new daemon holds the old keepalive pipe at fd 3 and has files from the old mount open. This is one concrete way to get #92. Closing the pipe in the payload child before exec (as #138 does) or marking it O_CLOEXEC would stop the leak.

🤖 Generated with Claude Code

主要言語
C
スター
74
フォーク
38
平均マージ
3時間 31分
マージ済み PR（30日）
1

環境構築

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

はじめの一歩

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

AppImage/type2-runtime のほかの issue

AppImage/type2-runtime の issue をすべて見る

似ている issue

C の issue をもっと見る

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

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