Dear Debian Hyprland Maintainers,
hyprpaper reproducibly segfaults when HDMI displays are power-cycled
(disconnected/reconnected) under Hyprland on Debian Trixie with
trixie-backports on arm64.
I investigated the crash under GDB. The evidence indicates a C++ ABI /
class-layout mismatch between Hyprutils 0.13.1, against which hyprpaper
is built, and Hyprutils 0.11.1, against which libhyprtoolkit5 is built.
Relevant installed packages:
hyprpaper 0.8.4-1~bpo13+1
libhyprtoolkit5 0.5.3-1~bpo13+1
libhyprgraphics4 0.5.1-2~bpo13+1
libaquamarine9 0.10.0-2~bpo13+1
libhyprutils10 0.11.1-1~bpo13+1
libhyprutils12 0.13.1-2~bpo13+1
ELF NEEDED entries show:
/usr/bin/hyprpaper:
libhyprutils.so.12
libhyprtoolkit.so.5
libhyprtoolkit.so.0.5.3:
libhyprutils.so.10
libhyprgraphics.so.4
libaquamarine.so.9
libhyprgraphics.so.0.5.1:
libhyprutils.so.10
libaquamarine.so.0.10.0:
libhyprutils.so.10
Both Hyprutils ABI generations are therefore mapped simultaneously in
the crashing hyprpaper process.
REPRODUCTION
1. Run hyprpaper normally under Hyprland with two HDMI outputs.
2. Power the displays off.
3. Power the displays back on.
4. hyprpaper receives SIGSEGV during the output lifecycle.
The failure has been reproduced multiple times.
GDB captured the crash on the main thread:
Thread 1 "hyprpaper" received signal SIGSEGV
pc = 0x555555ea5150
si_addr = 0x555555ea5150
si_code = 2
0x555555ea5150 lies in the process heap, which is writable but not
executable.
The caller is:
Hyprutils::Animation::CGenericAnimatedVariable<
Hyprtoolkit::CHyprColor,
Hyprtoolkit::SAnimationContext
inside libhyprtoolkit.so.5.
Relevant AArch64 instructions are:
ldr x3, [x20, #16]
cbz x3, ...
mov x1, x20
mov x0, x20
mov w2, #3
blr x3
At the crash:
x19 = base address of the CGenericAnimatedVariable object
x20 = x19 + 0xa0
x3 = 0x555555ea5150
Inspection of 0x555555ea5150 shows that it is a heap object whose first
word resolves to:
vtable for Hyprtoolkit::CRectangleElement + 16
The destructor is therefore attempting an indirect branch through a
CRectangleElement object pointer.
I compared the exact CBaseAnimatedVariable layouts for the two
Hyprutils versions.
Hyprutils 0.11.1:
m_fEndCallback offset 0x60
m_fBeginCallback offset 0x80
m_fUpdateCallback offset 0xa0
sizeof 0xc0
Hyprutils 0.13.1:
m_fEndCallback offset 0x70
m_fBeginCallback offset 0x90
m_fUpdateCallback offset 0xb0
sizeof 0xd0
The callback members therefore moved forward exactly 0x10 (16) bytes
between these ABI versions.
The newer CBaseAnimatedVariable layout contains additional
spring-animation state before the callbacks.
The destructor emitted in libhyprtoolkit.so.5 accesses the callbacks
using the Hyprutils 0.11.1 offsets.
For example, it treats object + 0xa0 as a std::function and obtains what
it believes is the manager pointer from object + 0xb0.
For an object laid out according to Hyprutils 0.13.1, however,
object + 0xb0 is the beginning of m_fUpdateCallback's callable payload.
In this crash that payload contains a CRectangleElement pointer.
The old-layout destructor therefore effectively performs:
blr CRectangleElement*
and attempts to execute a non-executable heap address, producing
SIGSEGV / SEGV_ACCERR.
The object's memory matches the Hyprutils 0.13.1 layout, while the
member accesses emitted by libhyprtoolkit match the Hyprutils 0.11.1
layout exactly.
The currently installable dependency graph is effectively:
hyprpaper
-> libhyprutils.so.12
-> libhyprtoolkit.so.5
-> libhyprutils.so.10
-> libhyprgraphics.so.4 -> libhyprutils.so.10
-> libaquamarine.so.9 -> libhyprutils.so.10
This appears to be an ABI-incompatible package combination in
trixie-backports. A coherent rebuild of the affected Hypr stack against
the same Hyprutils ABI appears necessary.
Expected result:
hyprpaper should survive normal output disconnect/reconnect events
without terminating.
I have attached the complete GDB crash capture as
hyprpaper-crash.txt and can provide additional diagnostic information
if useful.
Thank you.