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.
Nautilus segfaults (double-free of GMenu) when opening a new window
Reported by UstymUkhman · filed Sep 3, 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
Summary
Nautilus 50.2.2-1 segfaults shortly after nautilus --new-window runs. The symbolized stack (Arch debuginfod) shows a double-free / use-after-free of a `GMenu` during context-menu construction on the main thread.
nautilus 50.2.2-1, glib2 2.88.3-1, nautilus-python 4.1.0-3, Arch + Hyprland (Omarchy config).
Evidence
#0 g_atomic_ref_count_dec (arc=0x561200000040) refcount.c:247 <- garbage/invalid pointer
#1 g_hash_table_unref (hash_table=0x561200000000) ghash.c:1444
#2 g_menu_clear_item (gmenu.c:449)
#3 g_menu_finalize (gmenu.c:516)
#4 g_object_unref (gobject.c:4910)
#5 g_hash_table_remove_all_nodes (ghash.c:665) -> g_object_unref
#6 g_hash_table_unref (ghash.c:1446/1440)
#7 g_menu_clear_item (gmenu.c:449)
#8 g_menu_finalize (gmenu.c:516)
#9 g_object_unref (gobject.c:4910)
#10 ?? (nautilus +0xb33c5 / +0xa0da0) (unsymbolized)
#14 g_closure_invoke -> signal_emit (signal_id=417)
#20 ?? (nautilus +0xaf14a / +0x3f49b) (unsymbolized)
#21 g_idle_dispatch -> g_main_context_iteration -> g_application_runThe nested g_menu_finalize → g_hash_table_unref → g_menu_clear_item on both sides and the non-canonical arc pointer indicate a GMenu/GMenuItem torn down twice while still referenced. It crashed during a signal/idle callback building a context menu as part of g_application_run, with glycin thumbnailer buffers and gvfs-metadata logs open (a folder of images/video was being viewed/thumbnailed).
Recurs: a near-identical nautilus SIGSEGV (--new-window, menu emission) is recorded on 2026-08-26 too.
Suspected trigger (caveated)
Two Omarchy-shipped Nautilus.MenuProvider Python extensions are loaded and were both rewritten at 2026-09-02 18:30 (the pacman reinstall moment):
~/.local/share/nautilus-python/extensions/transcode.py~/.local/share/nautilus-python/extensions/localsend.py
Both return Nautilus.MenuItems from get_file_items, the path executing at the crash. The nautilus-native frames could not be symbolized (no debug symbols), so the exact nautilus function is unconfirmed; the crash may be Nautilus's own startup window-menu construction rather than the extensions.
Repro / confirm
nautilus --new-windowinto a folder of images/videos.- To test the extensions: move both
.pyfiles out of~/.local/share/nautilus-python/extensions/and repeat. If the crash stops, the extensions are implicated.
Expected / impact
Opening a new window should not crash. No user data lost (in-memory only; no files touched).
Filed by big-pickle via opencode.
View raw text
## Summary Nautilus `50.2.2-1` segfaults shortly after `nautilus --new-window` runs. The symbolized stack (Arch debuginfod) shows a **double-free / use-after-free of a `GMenu`** during context-menu construction on the main thread. `nautilus 50.2.2-1`, `glib2 2.88.3-1`, `nautilus-python 4.1.0-3`, Arch + Hyprland (Omarchy config). ## Evidence ``` #0 g_atomic_ref_count_dec (arc=0x561200000040) refcount.c:247 <- garbage/invalid pointer #1 g_hash_table_unref (hash_table=0x561200000000) ghash.c:1444 #2 g_menu_clear_item (gmenu.c:449) #3 g_menu_finalize (gmenu.c:516) #4 g_object_unref (gobject.c:4910) #5 g_hash_table_remove_all_nodes (ghash.c:665) -> g_object_unref #6 g_hash_table_unref (ghash.c:1446/1440) #7 g_menu_clear_item (gmenu.c:449) #8 g_menu_finalize (gmenu.c:516) #9 g_object_unref (gobject.c:4910) #10 ?? (nautilus +0xb33c5 / +0xa0da0) (unsymbolized) #14 g_closure_invoke -> signal_emit (signal_id=417) #20 ?? (nautilus +0xaf14a / +0x3f49b) (unsymbolized) #21 g_idle_dispatch -> g_main_context_iteration -> g_application_run ``` The nested `g_menu_finalize → g_hash_table_unref → g_menu_clear_item` on both sides and the non-canonical `arc` pointer indicate a `GMenu`/`GMenuItem` torn down twice while still referenced. It crashed during a signal/idle callback building a context menu as part of `g_application_run`, with `glycin` thumbnailer buffers and gvfs-metadata logs open (a folder of images/video was being viewed/thumbnailed). Recurs: a near-identical nautilus SIGSEGV (`--new-window`, menu emission) is recorded on 2026-08-26 too. ## Suspected trigger (caveated) Two Omarchy-shipped `Nautilus.MenuProvider` Python extensions are loaded and were both rewritten at `2026-09-02 18:30` (the pacman reinstall moment): - `~/.local/share/nautilus-python/extensions/transcode.py` - `~/.local/share/nautilus-python/extensions/localsend.py` Both return `Nautilus.MenuItem`s from `get_file_items`, the path executing at the crash. The nautilus-native frames could not be symbolized (no debug symbols), so the exact nautilus function is **unconfirmed**; the crash may be Nautilus's own startup window-menu construction rather than the extensions. ## Repro / confirm 1. `nautilus --new-window` into a folder of images/videos. 2. To test the extensions: move both `.py` files out of `~/.local/share/nautilus-python/extensions/` and repeat. If the crash stops, the extensions are implicated. ## Expected / impact Opening a new window should not crash. No user data lost (in-memory only; no files touched). > Filed by big-pickle via opencode.
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 10:40 UTC