nevaforget/moonlock
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

fix: prune per-monitor windows on monitor removal (v0.6.15)

Browse Source 
Resume-unlock SIGSEGV: connect_monitor only adds windows to all_handles,
never removes them when a monitor powers off on suspend. gtk4-session-lock
unmaps and drops its own ref, but the GtkApplication and all_handles keep
theirs, so the orphaned window survives until unlock — where destroying it
dereferences its now-NULL monitor association and crashes.

Watch display.monitors() and prune handles whose monitor is no longer
valid, releasing the app ref via remove_window (the lib already unmapped
and dereffed the window — we must not destroy it ourselves).

Revert the earlier idle_add_local_once deferral: the logs proved it
ineffective (crash happens inside the idle trampoline). Diagnostic unlock
logging kept until a suspend/resume cycle confirms the fix.
This commit is contained in:
nevaforget
2026-06-02 16:32:29 +02:00
parent 85cf039506
commit 492a781d92
6 changed files with 64 additions and 9 deletions
Download Patch File Download Diff File Expand all files Collapse all files
DECISIONS.md
+7
View File
@@ -2,6 +2,13 @@
Architectural and design decisions for Moonlock, in reverse chronological order.
## 2026-06-02 – Prune per-monitor windows on monitor removal to fix resume-unlock SIGSEGV (v0.6.15)
- **Who**: ClaudeCode, Dom
- **Why**: Chronic SIGSEGV (multiple coredumps/day) on the unlock following a suspend/resume. Backtrace: `app.quit()` → `gtk_window_destroy` → gtk4-layer-shell → `g_signal_emit` → NULL deref (`0x278`, rax=0). Root cause: `connect_monitor` is add-only — it creates one window per monitor and pushes to `all_handles`, but nothing ever removes a window when a monitor powers off on suspend. gtk4-session-lock unmaps + drops *its* ref to that window on monitor removal (per `gtk4-session-lock` 0.4 docs), but the GtkApplication (`ApplicationWindow::builder().application(app)`) and `all_handles` still hold refs. The orphaned window survives until unlock, where destroying it dereferences its now-NULL monitor association. A diagnostic confirmed the windows are GTK-valid but accumulate (3 windows for 1-2 monitors) with a NULL associated object.
- **Tradeoffs**: An earlier attempt deferred `unlock()`/`quit()` via `glib::idle_add_local_once` on a reentrancy theory — proven wrong by the logs (crash happens *inside* the idle trampoline). Reverted. The library doc explicitly says monitor removal is detected via "GTK APIs"; we follow that rather than fighting the library. We release our refs (do **not** call `destroy` — the lib already unmapped+dereffed the window). Diagnostic UNLOCK logging is kept for now, to be removed once a suspend/resume validation cycle confirms the fix.
- **How**: `LockscreenHandles` gains `monitor: Option<gdk::Monitor>`, set in the `connect_monitor` handler. `activate_with_session_lock` watches `display.monitors()` via `connect_items_changed`; on any change it retains only handles whose monitor `is_valid()`, calling `app.remove_window()` on the pruned ones to drop the application's ref. With both refs released, the orphaned window is gone before unlock.
## 2026-06-02 – Align power-confirm to moonset's ActionDef pattern (v0.6.14)
- **Who**: ClaudeCode, Dom