Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Abierto
  • ¿Algo no está bien?
#153 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
48/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
c, linux
Área
operating-systems

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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

Lenguaje dominante
C
Estrellas
74
Forks
38
Merge medio
3 h 31 min
PR fusionados (30 d)
1

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de AppImage/type2-runtime

Todos los issues de AppImage/type2-runtime

Issues similares

Más issues de C

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.