Linux ARM64 AppImage: zygote crashes with SIGBUS after orderly shutdown #24315

Activity

1. claytonfaria commented on Oct 24, 2026

   

   claytonfaria

   on Oct 24, 2026

   Author

   More actions

   Sanitized diagnostic evidence

   Adding the relevant shutdown and coredump excerpts. Identifying values and absolute timestamps have been removed. Relative timing is retained to show the event sequence. No raw core or full trace is attached.

   Shutdown timeline

   Times are relative to the start of the windowAllClosed span, rounded to milliseconds. Trace spans are summarized from the local structured logs; journal messages below are normalized/redacted excerpts.

   Relative time	Event	Result
   +0 to +4 ms	desktop.lifecycle.windowAllClosed	Success
   +0 to +249 ms	desktop.lifecycle.beforeQuit	Success; includes before-quit received
   +2 to +249 ms	desktop.lifecycle.requestShutdownAndWait	Success
   +41 to +249 ms	desktop.app.stopAllPoolInstances	Success
   +250 ms	desktop.app span ends	Success
   +578 ms	Main application scope resource accounting logged	Scope ended
   +585 ms	systemd-coredump reports zygote terminated with SIGBUS	Crash
   +586 ms	AppImage mount deactivated	Successful deactivation
   +784 ms	Core dump recorded	Recorded

   [+585 ms] systemd-coredump: Process <PID> (t3code) terminated abnormally
             with signal 7/BUS, processing...
   [+586 ms] systemd: <APPIMAGE_MOUNT>.mount: Deactivated successfully.
   [+784 ms] systemd-coredump: Process <PID> (t3code) dumped core.
   

   Importantly, the termination message was logged just before mount deactivation. These logs establish close timing, not proof that unmounting preceded or caused the fault.

   Coredump / debugger findings

   Process:      t3code
   Signal:       7 (BUS)
   Signal code:  BUS_ADRERR
   Command line: <APPIMAGE_MOUNT>/t3code --type=zygote
   Architecture: AARCH64
   Threads:      1
   
   GDB findings:
   - Fault address equals the program counter.
   - The address lies inside the AppImage t3code executable mapping.
   - Function names are unresolved.
   - Unwinding stopped at the fault frame.
   - The original mounted executable was unavailable at inspection time.
   

   A previous occurrence had the same zygote command, SIGBUS/BUS_ADRERR, corresponding executable fault offset, and same-second AppImage mount deactivation. This suggests recurrence of the helper shutdown pattern; it does not establish a deterministic reproducer.

   No OOM kill or relevant kernel I/O error was found in the inspected journal. Post-event memory measurements cannot exclude memory pressure at the time of the fault. The installed AppImage's modification time predated the event; an update occurring at shutdown was not established.

   The key distinction from the original #14259 report remains that the normal shutdown lifecycle completed successfully here. A helper outliving its AppImage backing mount is still a hypothesis, not a confirmed root cause. The precise app/Electron version remains unknown.
2. claytonfaria commented on Oct 24, 2026

   

   claytonfaria

   on Oct 24, 2026

   Author

   More actions

   Version clarification

   The earlier “unknown version” statement was an investigation gap. Read-only inspection of the installed AppImage now gives:

   • T3 Code 0.1.2 from the embedded application's package.json, corroborated by X-AppImage-Version in the bundled desktop entry.
   • Electron 44.9.3 from the bundled executable's Electron/44.9.3 string.
   • Chrome 152.0.7977.167 from the bundled executable's corresponding version string.

   The installed artifact's modification time predates the crash. These versions identify the inspected installed artifact; a build ID comparison against the crashed executable was not performed. This supersedes the unknown-version statement in the previous diagnostic comment. The issue body has also been corrected.

   Only product version metadata is included here; identifying local details remain omitted.