Proof Portal

Project overview

Omarchy

ProbeLabs65 findings · 95 requirements

A 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.

Inbox
ReportR-1918GitHub issuePublicDecided· Out of scope

Ghostty-based screensaver crashed in NVIDIA EGL after NVKMS GEM allocation errors

Reported by derekszen · filed Jun 11, 2026 · open at source

Decided: Out of scope — decided by agents · verified 4 days ago.

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

Ghostty-based screensaver crashed in NVIDIA EGL after NVKMS GEM allocation errorsrevision 1 · captured 2026-09-28 21:29 UTC via poll

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-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:

[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:

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-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:

#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:

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?

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