Proof Portal
Omarchy
ProbeLabs65 findings · 95 requirementsA proof layer — requirements, tests and verified fixes — for two of Omarchy's subsystems: the application menu (launcher scripts, QML model, JSONC config, search and selection) and the lock screen (lock scripts, QML, PAM authentication). Scope is deliberately limited to those components of omacom/omarchy; the rest of the distribution is not covered.
Ghostty-based screensaver crashed in NVIDIA EGL after NVKMS GEM allocation errors
Reported by derekszen · filed Jun 11, 2026 · open at source
At a glance
- 1 · What is claimed?
- Only the report text below — no validator has restated it as checkable claims yet.
- 2 · What does it affect?
- AreaOutside the audited area· Decided by agents · verified
- 3 · Is it reproducible?
- No validation has been run yet.
- 4 · What remains unclear?
- Not validated yet: no claims, no reproducer.
- 5 · What happens next?
- Decided by agents and verified by a second, independent agent — see the decision.
Original report
System details
Omarchy: 3.8.2
Hyprland: 0.55.2-2
Ghostty: 1.3.1-arch2
GTK4: 4.22.4-1
GPU: NVIDIA GeForce RTX 5090 D
Driver: 610.43.02
nvidia-open-dkms: 610.43.02-2
nvidia-utils: 610.43.02-2
Kernel: 7.0.11-arch1-1What's wrong?
I hit a crash/hang involving the Omarchy screensaver path on an NVIDIA system. I am not sure whether this is primarily an Omarchy issue, Ghostty/GTK4 issue, or NVIDIA driver issue, but the affected process was launched by the Omarchy screensaver command, so I am filing this here for tracking and to ask whether there is a recommended Omarchy-side workaround.
I also filed the NVIDIA-side incident here:
https://github.com/NVIDIA/open-gpu-kernel-modules/issues/1191
At 2026-06-11 15:15:10 CST, the kernel logged this NVIDIA DRM error twice:
[drm:nv_drm_gem_alloc_nvkms_memory_ioctl [nvidia_drm]] *ERROR* [nvidia-drm] [GPU ID 0x00000100] Failed to allocate NVKMS memory for GEM objectThen Ghostty crashed:
ghostty[1007163]: segfault at 0 ip 00007fe2a64f4390 sp 00007ffe361311d0 error 6 in libnvidia-eglcore.so.610.43.02[af4390,7fe2a5c19000+c46000] likely on CPU 7 (core 7, socket 0)The coredump command line was:
ghostty --class=org.omarchy.screensaver --config-file=~/.local/share/omarchy/default/ghostty/screensaver --font-size=18 -e omarchy-screensaverThe coredump shows SIGSEGV in /usr/bin/ghostty. The stack starts in libnvidia-eglcore.so.610.43.02, then continues through the GTK4 render stack:
#0 libnvidia-eglcore.so.610.43.02 + 0xaf4390
#1 libnvidia-eglcore.so.610.43.02 + 0xa38c33
#2 libnvidia-eglcore.so.610.43.02 + 0xa43b5c
#3 libnvidia-eglcore.so.610.43.02 + 0x77e3a4
#4 libgtk-4.so.1 + 0x5cf7b8
#7 gsk_renderer_render (libgtk-4.so.1 + 0x59d9a3)
#23 ghostty + 0x135de95The previous boot journal stopped at 15:15:24, and the next boot began at 15:16:35, which suggests the machine may have hung or rebooted abnormally shortly after the crash. I do not have a reliable reproduction yet, so I do not want to overstate causality.
After reboot, the GPU looked normal:
NVIDIA GeForce RTX 5090 D, 610.43.02, 32607 MiB total, 1926 MiB used, 35 C, 5% utilizationQuestion: is there a recommended Omarchy workaround for NVIDIA systems to avoid this path, such as disabling the Ghostty-based screensaver, switching the screensaver command to a simpler renderer, or changing the Ghostty/GTK rendering backend for the screensaver process only?
View raw text
### System details ```text Omarchy: 3.8.2 Hyprland: 0.55.2-2 Ghostty: 1.3.1-arch2 GTK4: 4.22.4-1 GPU: NVIDIA GeForce RTX 5090 D Driver: 610.43.02 nvidia-open-dkms: 610.43.02-2 nvidia-utils: 610.43.02-2 Kernel: 7.0.11-arch1-1 ``` ### What's wrong? I hit a crash/hang involving the Omarchy screensaver path on an NVIDIA system. I am not sure whether this is primarily an Omarchy issue, Ghostty/GTK4 issue, or NVIDIA driver issue, but the affected process was launched by the Omarchy screensaver command, so I am filing this here for tracking and to ask whether there is a recommended Omarchy-side workaround. I also filed the NVIDIA-side incident here: https://github.com/NVIDIA/open-gpu-kernel-modules/issues/1191 At `2026-06-11 15:15:10 CST`, the kernel logged this NVIDIA DRM error twice: ```text [drm:nv_drm_gem_alloc_nvkms_memory_ioctl [nvidia_drm]] *ERROR* [nvidia-drm] [GPU ID 0x00000100] Failed to allocate NVKMS memory for GEM object ``` Then Ghostty crashed: ```text ghostty[1007163]: segfault at 0 ip 00007fe2a64f4390 sp 00007ffe361311d0 error 6 in libnvidia-eglcore.so.610.43.02[af4390,7fe2a5c19000+c46000] likely on CPU 7 (core 7, socket 0) ``` The coredump command line was: ```text ghostty --class=org.omarchy.screensaver --config-file=~/.local/share/omarchy/default/ghostty/screensaver --font-size=18 -e omarchy-screensaver ``` The coredump shows `SIGSEGV` in `/usr/bin/ghostty`. The stack starts in `libnvidia-eglcore.so.610.43.02`, then continues through the GTK4 render stack: ```text #0 libnvidia-eglcore.so.610.43.02 + 0xaf4390 #1 libnvidia-eglcore.so.610.43.02 + 0xa38c33 #2 libnvidia-eglcore.so.610.43.02 + 0xa43b5c #3 libnvidia-eglcore.so.610.43.02 + 0x77e3a4 #4 libgtk-4.so.1 + 0x5cf7b8 #7 gsk_renderer_render (libgtk-4.so.1 + 0x59d9a3) #23 ghostty + 0x135de95 ``` The previous boot journal stopped at `15:15:24`, and the next boot began at `15:16:35`, which suggests the machine may have hung or rebooted abnormally shortly after the crash. I do not have a reliable reproduction yet, so I do not want to overstate causality. After reboot, the GPU looked normal: ```text NVIDIA GeForce RTX 5090 D, 610.43.02, 32607 MiB total, 1926 MiB used, 35 C, 5% utilization ``` Question: is there a recommended Omarchy workaround for NVIDIA systems to avoid this path, such as disabling the Ghostty-based screensaver, switching the screensaver command to a simpler renderer, or changing the Ghostty/GTK rendering backend for the screensaver process only?
Validation
Not checked yet. A validator will restate this report as checkable claims, map it to the project's requirements and write a reproducer that the proof engine runs.
Linked
Not linked to any known issue, other report or change yet.
Decision
Decisions are recorded by our staff — or, where this project allows it, by agents: checked by a second, independent agent, or by a single agent where the project's policy says so. Any decision reached so far is shown below.
- Out of scopeDecided by agents · verified · 2026-10-09 03:51 UTC