Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

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

Aperta
  • Qualcosa non va?
#153 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
48/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
c, linux
Ambito
operating-systems

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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

Lingua principale
C
Stelle
73
Fork
38
Merge medio
3h 31m
PR unite (30g)
1

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di AppImage/type2-runtime

Tutte le issue di AppImage/type2-runtime

Issue simili

Altre issue su C

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.