[Bug]: Linux/Hyprland desktop exits silently with no crash diagnostics #10911

Activity

1. juliusmarminge commented on Sep 9, 2026

   

   juliusmarminge

   on Sep 9, 2026

   Member

   More actions

   Triage

   Confirmed as a real desktop diagnostic gap, and not a duplicate of #10517 or #2216. The mid-session exit itself is still unexplained — one observation, no app-side logs, no crash artifact.

   What this is / is not

   Issue	Symptom	Process	Status
   #10911 (this)	Window/process gone mid-session	Exited (Result=success)	Open
   #10517	Blank window, backend child died at startup	Stays alive	Open, accepted
   #2216	Window never appears (ready-to-show on Wayland)	Stays alive	Fixed in #2262

   #4918 (closed, unmerged) is the same user outcome on AppImage relaunch (“quit and never came back”). t3code-bin is an extracted AppImage without $APPIMAGE, and Linux auto-update is disabled unless that env is set, so this is probably not an updater/relaunch miss.

   No open or merged PR fixes a mid-session silent exit under Hyprland/Wayland.

   What the journal actually shows

   app-t3code-87926.scope → inactive/dead, Result=success. That is exit code 0, not SIGSEGV, SIGKILL, or OOM.

   Together with no coredumpctl entry, no OOM, and Crashpad only having client_id, this looks like a clean shutdown or an uncaptured Chromium/Ozone abort, not a dumped native crash.

   What the desktop process does today

   On Linux, last window closed calls app.quit() (DesktopLifecycle window-all-closed). Hyprland closing the surface (killactive, close, or a Wayland protocol error) is enough to make the app disappear with no dialog.

   SIGINT / SIGTERM are treated as a normal quit (quitFromSignal → app.quit()), which also yields Result=success.

   Visible errors are startup-only (whenReady / bootstrap → showErrorBox). Mid-session, there is no terminal UI.

   Crash reporting is effectively off:

   • crashReporter.start() is never called, so Crashpad often leaves only client_id.
   • No uncaughtException / unhandledRejection.
   • No child-process-gone / gpu-process-crashed handlers. render-process-gone only logs and may reload the renderer; it does not keep a dead main process on screen.

   Logging: Effect goes to stdout (Logger.consolePretty) plus ~/.t3/userdata/logs/desktop.trace.ndjson. gtk-launch uses Terminal=false, so stdout never hits the journal. There is no rotating desktop-main.log. Backend child output is ~/.t3/userdata/logs/server-child.log and would not take down the Electron window by itself (#10517).

   Forced --ozone-platform=wayland on Intel UHD 630 + GTX 1050 Ti Mobile is a known Chromium/Electron hazard (wrong GPU, Vulkan/Ozone mismatch, GPU process death). Some of those paths exit 0 and skip Crashpad.

   Likely causes (unconfirmed)

   1. Last window closed → Linux quit-on-last-window (compositor or user).
   2. Ozone/GPU abort on hybrid Wayland that still exits 0.
   3. SIGTERM from the session/uwsm, then our clean signal quit.

   Need traces to tell these apart.

   Suggested next step

   Not starting a crash-reporter or Wayland-GPU change until we have one more data point.

   Please attach, if they still exist:

   1. ~/.t3/userdata/logs/desktop.trace.ndjson from 10:55–11:03 CEST — look for before-quit received, desktop.lifecycle.windowAllClosed, process signal received, main window render process gone.
   2. ~/.t3/userdata/logs/server-child.log for the same window (rules out a child crash-loop).
   3. Whether the window was closed / killactive / Ctrl+Q, or it vanished while focused and idle.
   4. Any Hyprland/NVIDIA/Mesa lines in journalctl --user for that interval (the snippet only has the scope start + relaunch).

   If it happens again:

   ELECTRON_ENABLE_LOGGING=1 ELECTRON_OZONE_PLATFORM_HINT=auto t3code

   Workaround to try: --ozone-platform=x11 (or drop the forced Wayland flag) on this hybrid box.

   If traces show before-quit / windowAllClosed, this is quit-on-last-window and we should log a reason and/or keep the process. If traces just stop, next product work is a real mid-session diagnostic (file log + Crashpad start() + GPU/child-process handlers), related to #10517 but scoped to “the desktop process vanished.”
2. juliusmarminge

   added

   bugSomething is broken or behaving incorrectly.Something is broken or behaving incorrectly.

   needs more infoInitial triage showed no bug. Awaiting more infoInitial triage showed no bug. Awaiting more info

   via-triageFiled through npx t3 triageFiled through npx t3 triage

   on Sep 9, 2026
3. Vanir20342222 commented on Sep 9, 2026

   

   Vanir20342222

   on Sep 9, 2026

   Last edited by Vanir20342222

   Author

   More actions

   AI model: gpt-5.6-luna

   Thanks for the detailed triage. I checked the requested evidence locally and found no sensitive data that should be attached.

   • desktop.trace.ndjson is present, but there is no before-quit, windowAllClosed, signal, renderer-process-gone, or GPU-process-crashed event in the relevant interval.
   • The trace contains the normal startup/window-created sequence after the relaunch, but no corresponding shutdown reason for the previous session.
   • server-child.log is not present. The available server trace shows normal activity around the relaunch and no backend crash or crash-loop.
   • The user journal has the app-scope start and subsequent relaunch, plus unrelated xkbcomp warnings; I found no NVIDIA/Mesa/Wayland/GPU error for that interval.
   • I have no evidence that the window was deliberately closed, killactive/Ctrl+Q was used, or that a GPU abort occurred, so the trigger remains unknown.

   So this still looks like an uncaptured clean exit or compositor/Electron termination, with no local trace that distinguishes those cases. I have not attached the raw logs because they include local environment/project details. I’ll try the --ozone-platform=x11 workaround if it recurs, and will capture a focused trace with logging enabled before relaunching.
4. kyryl-bogach commented on Sep 17, 2026

   

   kyryl-bogach

   on Sep 17, 2026

   More actions

   Same failure on Arch + Hyprland, on 0.0.42. I have data that narrows this down: the backend child died first, and the desktop shell then quit itself on purpose. The shell is a victim, not the cause.

   Environment

   • t3code-bin 0.0.42-1 (Arch AUR), kernel 7.2.5-3-omarchy
   • Hyprland 0.56.2, Wayland, launched with --ozone-platform=wayland
   • AMD Ryzen 9 5900X (24 threads), NVIDIA RTX 5080
   • 62 GiB RAM, 125 GiB swap. 38 GiB available at the time.

   Incident

   Session started 2026-09-17 09:23:33 CEST, died 09:40:20 CEST. No user action, an agent run was streaming.

   ~/.t3/userdata/logs/desktop.trace.ndjson holds the cause. The span for runBackendProcess, opened at session start, closes with:

   runBackendProcess | Failure
   BackendProcessExitStatusError: Failed to read the exit status of desktop backend process 9150.
       at .../apps/desktop/dist-electron/main.cjs:110323:67
       at .../apps/desktop/dist-electron/main.cjs:4245:91
       at ~effect/Utils/internal (.../main.cjs:1464:11)
       at runBackendProcess (.../main.cjs:110509:19)
       at runBackendProcess (definition) (.../main.cjs:110247:27)
       at desktop.backendInstance.start (.../main.cjs:110550:12)
   

   The shell then ran an orderly shutdown, which is why systemd sees a clean exit and why there is no crash artifact:

   09:40:18  desktop.window.handleBackendNotReady   Success
   09:40:18  desktop.lifecycle.windowAllClosed      Success
   09:40:18  desktop.lifecycle.beforeQuit           Success
   09:40:18  desktop.lifecycle.requestShutdownAndWait  Success
   09:40:18  desktop.app.stopAllPoolInstances       Success
   09:40:18  desktop.backendInstance.stop           Success
   09:40:20  desktop.backendInstance.finalizeRun    Success
   09:40:20  PreviewManager.destroy                 Success
   

   The backend leaves no error of its own

   server.trace.ndjson stops dead at 09:39:28, roughly 50 seconds before the shell gives up. The last line is a normal handleSdkMessage span with "exit":{"_tag":"Success"}. There is no error record, no shutdown span, nothing. The process had no chance to write one.

   Workload in its final 90 seconds, by span name:

       901  updateResumeCursor
       883  ensureThreadId
       883  handleSdkMessage
       825  handleStreamEvent
       812  sql.execute
       131  sql.transaction
        90  ProjectionSnapshotQuery.getThreadRuntimeContext
        87  PortDiscovery.registerTerminalProcesses
        64  applyThreadMessagesProjection
        64  applyThreadsProjection
        64  applyThreadTurnsProjection
        64  applyThreadActivitiesProjection
        64  applyThreadSessionsProjection
        64  applyThreadProposedPlansProjection
        64  applyPendingApprovalsProjection
        64  applyProjectsProjection
        64  decideOrchestrationCommand
   

   883 SDK messages in 90 seconds, each driving a SQLite write plus a full rebuild of eight projections. Provider was claudeAgent on a long-running thread.

   systemd accounting

   app-com.t3tools.T3Code-8984.scope: Consumed 24min 41.687s CPU time
   over 16min 47.416s wall clock time, 25.6G memory peak.
   

   Caveat on that number: cgroup memory.peak counts page cache, so it overstates real usage. In the session that followed I measured MemoryPeak=5.7G against MemoryCurrent=544M, with about 1.3 GB of actual process RSS. So 25.6 G is not by itself proof of a leak. The CPU figure is solid: about 1.5 cores sustained for 17 minutes.

   Causes ruled out

   • Kernel OOM killer: no event. 38 GiB was available.
   • systemd-oomd (the mechanism in [Bug]: systemd-oomd kills the entire T3 Code scope when an agent-spawned child workload exhausts memory (Linux) #5248): active and enabled on this machine, logged no kill. app-graphical.slice has MemoryHigh=infinity and MemoryMax=infinity, so no cgroup limit applied.
   • Core dump: none. coredumpctl has no entry for t3code. An unrelated Node OOM on this machine two days earlier did produce a dump, so core dumps do work here. Electron's own handler suppresses them for t3code.
   • Crashpad: no report. ~/.config/t3code/Crashpad/ holds only client_id.
   • Hardware: no MCE or ECC errors, no NVMe or filesystem I/O errors in 7 days.
   • Package upgrade: ruled out. A separate app exit on 2026-09-16 at 21:39:49 turned out to be pacman upgrading 0.0.40-1 to 0.0.42-1 eighteen seconds earlier. Worth knowing when reading Linux reports: an in-place upgrade looks identical to a silent crash in the journal.

   What is still unknown

   Whether the backend hit the V8 heap cap, took a native crash, or was killed. Nothing on this machine records it.

   Two things would close that gap:

   1. The backend should log its own death. Right now an abrupt exit produces zero diagnostics on either side. BackendProcessExitStatusError says the parent could not even read the exit status, which is its own bug.
   2. Surface the child's stderr. A V8 abort prints FATAL ERROR: ... JavaScript heap out of memory to stderr and nowhere else. Neither trace log captures it, so it is lost unless the app is started from a terminal. I am running that way now and will report back if it reproduces.

   Trace excerpts

   https://gist.github.com/kyryl-bogach/9d260d7ba4c1c98d12b7489176feaf9d

   • server-final-120s.ndjson - the backend's last 120 seconds. The file ends where the process died, mid stream, with no error record.
   • desktop-shutdown.ndjson - the detection and shutdown, including the runBackendProcess Failure span.

   These are rebuilt from a field allowlist rather than scrubbed, so nothing outside the allowlist can appear. The gist README lists exactly what is kept and what is dropped.

   Two things I had to drop are worth naming. git.cwd carries absolute paths to private repositories. url.full carries a wsTicket bearer token in plain text, 31 times in one rotated file. A credential written unredacted into local trace logs may deserve its own issue.

   Happy to supply more on request.