Hacktoberfest 2026：维护者为十月标记出来的 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 个 reaction 已指派 0 人 在 GitHub 查看

还没有人认领这个 Issue。

评估

难度
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
星标
73
派生
38
平均合并
3 小时 31 分钟
30 天内合并 PR
1

环境准备

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

从这里开始

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

AppImage/type2-runtime 的其他 Issue

查看 AppImage/type2-runtime 的全部 Issue

相似的 Issue

更多 C Issue

把新 issue 发到你的邮箱

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