[Linux/Nobara/AMD] ChatGPT 26.818.21641 repeatedly SIGSEGVs in GPU, renderer, and bundled Codex processes

Open 💬 2 comments Opened Aug 20, 2026 by Kizuno18

💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Codex app version

26.818.21641 (RPM), with bundled codex-cli 0.148.0-alpha.21

ChatGPT plan

Unknown / not relevant to the native crash

Platform

Nobara 44 (Fedora 44), Linux 7.1.4-200.nobara.fc44.x86_64, KDE Wayland, AMD Navi 10 GPU, Mesa 26.2.0

What happened?

The Linux Codex app crashed repeatedly during normal use on August 20. systemd-coredump retained eight SIGSEGVs from /usr/lib/chatgpt/ChatGPT across GPU, renderer, and utility processes, plus three SIGSEGVs from the bundled resources/codex binary.

One GPU-process core has this top frame:

amdgpu_bo_slab_free (libgallium-26.2.0.so + 0xbaddc9)
pb_slabs_reclaim_locked
pb_slab_alloc_reclaimed
amdgpu_bo_create
si_alloc_resource

The bundled Codex crashes had top offsets +0x438b251, +0xc2205ea, and +0xc21f5b4. The last two were also logged by the kernel as general protection faults in tokio-rt-worker.

Steps to reproduce

I do not have a deterministic minimal reproduction. Run the app normally on this AMD/Mesa system; the crashes occurred across several process types during one session.

Expected behavior

The app and its bundled Codex process should remain running without native faults.

Additional information

This host also showed cross-process memory-corruption symptoms that day, including an unrelated compiler Bad page state and a kernel Oops in lruvec_stat_mod_folio. NVMe SMART is clean and a full Btrfs scrub found no errors. Because of that, hardware or kernel corruption may be contributing; I am reporting the repeatable app-specific signatures without claiming every event is an independent Codex defect.

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 7 days ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

#38879

Powered by Codex Action

Kizuno18 · 7 days ago

One more GPU-process core was captured after the reboot into 7.1.4. This is a different Mesa/Gallium signature from the amdgpu_bo_slab_free crash in the issue body.

Environment:

ChatGPT 26.818.21641-1
Mesa Freeworld 26.2.0-1.fc44
GPU subprocess using --ozone-platform=x11
SIGSEGV

Top crashing thread:

util_unreference_framebuffer_state (libgallium-26.2.0.so + 0x7c0318)
tc_batch_execute                  (libgallium-26.2.0.so + 0x7cfe5d)
util_queue_thread_func           (libgallium-26.2.0.so + 0x5c01be)
impl_thrd_routine                (libgallium-26.2.0.so + 0x60a70c)

The main GPU thread was waiting in _tc_sync/tc_flush, followed by the Mesa DRI3/GLX swap-buffer path. The local crash watcher retained the full core metadata. This occurred only a few minutes after the earlier system-level hard hang, so it may still be downstream of kernel or hardware memory corruption rather than an independent application defect.