blob: d67ca1d2998ae2865ce012dd20808b594063fd0a (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
|
* screenshot.py --launch likely crashed Hyprland (2026-06-10 15:15)
While capturing a throwaway Emacs frame for theme-studio bevel work on ratio, the screenshot harness's --launch mode (create a headless output, render the app there, capture, tear down) appears to have crashed Hyprland.
Timeline, from instance dirs and pid start times:
- 15:14 — screenshot.py --launch 'emacs -Q --eval ...' --layout floating ran and returned a PNG (the Emacs window never appeared in it; the capture shows only waybar on the headless output).
- 15:15:32 — a new Hyprland instance dir appeared (first restart).
- 15:15:40 — a second new instance dir; the surviving Hyprland pid (1171040) started 15:15:39. So the compositor died, and its first respawn died too, within 8 seconds.
- The session's original instance (02:08) socket was gone afterward. All Wayland windows from before 15:15 died with it.
The machine was otherwise idle (Craig away, only the Claude session active), so the headless-output create/teardown is the prime suspect — possibly interacting with the strix kernel (6.18.25-1-lts-strix) or the floating-layout window move. A second --launch attempt a minute later failed differently (stale HYPRLAND_INSTANCE_SIGNATURE in the session env), so the crash path was only exercised once.
What this asks of archsetup:
1. Check Hyprland logs / coredumpctl around 2026-06-10 15:15 on ratio for the crash signature.
2. Review the --launch teardown ordering in the screenshot harness (output removal while a client window is mid-map seems like the risky window, given the captured PNG shows the launched app never mapped).
3. Until understood, treat --launch as unsafe on a live session; the other modes (--full, --window, --active) don't touch outputs and stayed fine.
The .emacs.d session paged Craig at the time and avoided --launch for the rest of the day. Happy to provide the exact command and PNG (/tmp/emacs-bevel-ref.png) if they help.
|
