ChatGPT desktop segfaults on launch on Ubuntu 26.04.1; crash traced to libgio/GDBus, not a config or keyring issue

ChatGPT Bugs
, , ,
1

The ChatGPT desktop app (.deb, version 26.901.31953) segfaults immediately on every launch. This reproduces identically on a clean reinstall with zero prior state. I fully purged the package, deleted all local config and cache (~/.config/Codex), and reinstalled from scratch, and it still crashes the same way. It also matches another user’s bug on the same OS version with different hardware (AMD/Nvidia there, Intel here), so this looks like a real regression against something in this Ubuntu release, not a local machine issue.
System:

  • Ubuntu 26.04.1 LTS, kernel 7.0.0-31-generic, x86_64
  • GPU: Intel Raptor Lake-P Iris Xe
  • libglib2.0-0t64: 2.88.0-1
  • ChatGPT desktop version: 26.901.31953 (latest available via your apt repo as of Sept 4 2026)

Steps to reproduce:

  1. sudo apt install ./chatgpt_amd64.deb (fresh install, or on top of a full purge, same result either way)
  2. chatgpt from a terminal
  3. Immediate Segmentation fault (core dumped)

What I ruled out (each independently tested and confirmed not the cause):

  • Corrupt or stale local profile: a fresh ~/.config/Codex still crashes.
  • Password-store/keyring backend: chatgpt --password-store=basic still crashes.
  • D-Bus session bus availability: crashes identically with DBUS_SESSION_BUS_ADDRESS unset.
  • Missing shared libraries: ldd on the binary shows nothing unresolved.
  • Stale package version: already on the latest build from your repo.

Actual crash location (via coredumpctl and gdb on the core dump, reproduced across 3 separate runs with identical relative offsets):

Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x000078e91a7afc00 in ?? ()
#1  0x000078e9a4b0ed8f in ?? () from libgio-2.0.so.0
#2  0x000078e9a4b1355d in ?? () from libgio-2.0.so.0
#3  0x000078e9a4aa25eb in ?? () from libgio-2.0.so.0
#4  0x000078e9a4aa7d90 in ?? () from libgio-2.0.so.0
#5  0x000078e9a4b0e072 in ?? () from libgio-2.0.so.0
#6  0x000078e9a4aa25eb in ?? () from libgio-2.0.so.0
#7  0x000078e9a4aa2625 in ?? () from libgio-2.0.so.0
#8  0x000078e9a4e6cb9b in ?? () from libglib-2.0.so.0
#9  0x000078e9a4e6e1d7 in ?? () from libglib-2.0.so.0
#10 0x000078e9a4e6e3c3 in g_main_context_iteration () from libglib-2.0.so.0

Crash frame #4 sits right after an indirect call *%rax near the exported symbol g_dbus_connection_call_with_unix_fd_list_sync in libgio-2.0.so.0.8800.0. That places the fault inside async GDBus machinery on startup, the code path Chromium’s OSCrypt/password-store uses to talk to the Secret Service over D-Bus, not a random memory-corruption crash elsewhere. The main browser process also received a self-raised SIGSEGV (si_code=SI_USER per strace), consistent with a fatal GLib/GObject assertion rather than a stray pointer dereference.

Ask: This looks like an ABI or behavior mismatch between the bundled Electron/Chromium build’s GDBus usage and libglib2.0/libgio 2.88.0-1 as shipped in Ubuntu 26.04. Could someone confirm whether this build has been tested against glib 2.88? The crashpad/ERROR: read out of range lines in the console output are a red herring. That’s just the crash reporter itself failing to attach under Yama ptrace restrictions after the real SIGSEGV already happened, not the actual bug.

Happy to provide the full core dump or run further diagnostics if useful.