[Solved] Hyprland crashes on startup

Message

Nima0908 · Post by **Nima0908** » Sat Mar 14, 2026 4:24 pm

Hello,
if i try to start hyprland through

dbus-run-session start-hyprland

it instantly crashes with the following crash report:

Code: Select all

 --------------------------------------------
   Hyprland Crash Report
--------------------------------------------
Oops

Hyprland received signal 11(unknown)
Version: 59f9f2688ac508a0584d1462151195a6c4992f99
Tag: v0.54.2
Date: Tue Mar 10 13:26:58 2026
Flags:
no xwayland

System info:
	System name: Linux
	Node name: gentoo
	Release: 6.18.12-gentoo
	Version: #5 SMP PREEMPT Mon Mar  9 18:57:08 CET 2026

GPU:
	01:00.0 VGA compatible controller [0300]: NVIDIA Corporation AD107 [GeForce RTX 4060] [10de:2882] (rev a1) (prog-if 00 [VGA controller])


os-release:
	NAME=Gentoo
	ID=gentoo
	PRETTY_NAME="Gentoo Linux"
	ANSI_COLOR="1;32"
	HOME_URL="https://www.gentoo.org/"
	SUPPORT_URL="https://www.gentoo.org/support/"
	BUG_REPORT_URL="https://bugs.gentoo.org/"
	VERSION_ID="2.18"

Libraries:
Hyprgraphics: built against 0.5.0, system has 0.5.0
Hyprutils: built against 0.11.0, system has 0.11.0
Hyprcursor: built against 0.1.13, system has 0.1.13
Hyprlang: built against 0.6.8, system has 0.6.8
Aquamarine: built against 0.10.0, system has 0.10.0

Backtrace:
	# | configuration does not support execinfo.h
		??
		??:0


Log tail:
DEBUG from aquamarine ]: drm: Skipping connector DP-3, has crtc 67 and is connected
DEBUG from aquamarine ]: drm: slot 0 crtc 67 taken by DP-3, skipping
DEBUG from aquamarine ]: drm: slot 1 crtc 82 unassigned
DEBUG from aquamarine ]: drm: slot 2 crtc 97 unassigned
DEBUG from aquamarine ]: drm: slot 3 crtc 112 unassigned
DEBUG from aquamarine ]: drm: Connector DP-1 is not connected
DEBUG from aquamarine ]: drm: Connector DP-2 is not connected
DEBUG from aquamarine ]: drm: Connector HDMI-A-1 is not connected
DEBUG from aquamarine ]: drm: Connector DP-3 connected
DEBUG from aquamarine ]: drm: Connecting connector DP-3, CRTC ID 67
DEBUG from aquamarine ]: drm: Dumping detected modes:
DEBUG from aquamarine ]: drm: Mode 0: 3440x1440@60.00Hz  (preferred)
DEBUG from aquamarine ]: drm: Mode 1: 3440x1440@100.00Hz 
DEBUG from aquamarine ]: drm: Mode 2: 3440x1440@75.00Hz 
DEBUG from aquamarine ]: drm: Mode 3: 3440x1440@30.00Hz 
DEBUG from aquamarine ]: drm: Mode 4: 2560x1440@120.00Hz 
DEBUG from aquamarine ]: drm: Mode 5: 2560x1080@60.00Hz 
DEBUG from aquamarine ]: drm: Mode 6: 2560x1080@59.94Hz 
DEBUG from aquamarine ]: drm: Mode 7: 2560x1080@50.00Hz 
DEBUG from aquamarine ]: drm: Mode 8: 1920x1080@120.00Hz 
DEBUG from aquamarine ]: drm: Mode 9: 1920x1080@119.88Hz 
DEBUG from aquamarine ]: drm: Mode 10: 1920x1080@60.00Hz 
DEBUG from aquamarine ]: drm: Mode 11: 1920x1080@60.00Hz 
DEBUG from aquamarine ]: drm: Mode 12: 1920x1080@59.94Hz 
DEBUG from aquamarine ]: drm: Mode 13: 1920x1080@50.00Hz 
DEBUG from aquamarine ]: drm: Mode 14: 1680x1050@59.95Hz 
DEBUG from aquamarine ]: drm: Mode 15: 1280x1024@75.03Hz 
DEBUG from aquamarine ]: drm: Mode 16: 1280x1024@60.02Hz 
DEBUG from aquamarine ]: drm: Mode 17: 1440x900@59.89Hz 
DEBUG from aquamarine ]: drm: Mode 18: 1280x720@60.00Hz 
DEBUG from aquamarine ]: drm: Mode 19: 1280x720@59.94Hz 
DEBUG from aquamarine ]: drm: Mode 20: 1280x720@50.00Hz 
DEBUG from aquamarine ]: drm: Mode 21: 1024x768@99.99Hz 
DEBUG from aquamarine ]: drm: Mode 22: 1024x768@75.03Hz 
DEBUG from aquamarine ]: drm: Mode 23: 1024x768@70.07Hz 
DEBUG from aquamarine ]: drm: Mode 24: 1024x768@60.00Hz 
DEBUG from aquamarine ]: drm: Mode 25: 832x624@74.55Hz 
DEBUG from aquamarine ]: drm: Mode 26: 800x600@99.86Hz 
DEBUG from aquamarine ]: drm: Mode 27: 800x600@75.00Hz 
DEBUG from aquamarine ]: drm: Mode 28: 800x600@72.19Hz 
DEBUG from aquamarine ]: drm: Mode 29: 800x600@60.32Hz 
DEBUG from aquamarine ]: drm: Mode 30: 800x600@56.25Hz 
DEBUG from aquamarine ]: drm: Mode 31: 720x576@50.00Hz 
DEBUG from aquamarine ]: drm: Mode 32: 720x480@60.00Hz 
DEBUG from aquamarine ]: drm: Mode 33: 720x480@59.94Hz 
DEBUG from aquamarine ]: drm: Mode 34: 640x480@99.83Hz 
DEBUG from aquamarine ]: drm: Mode 35: 640x480@75.00Hz 
DEBUG from aquamarine ]: drm: Mode 36: 640x480@72.81Hz 
DEBUG from aquamarine ]: drm: Mode 37: 640x480@66.67Hz 
DEBUG from aquamarine ]: drm: Mode 38: 640x480@60.00Hz 
DEBUG from aquamarine ]: drm: Mode 39: 640x480@59.94Hz 
DEBUG from aquamarine ]: drm: Mode 40: 720x400@70.08Hz 
DEBUG from aquamarine ]: drm: Physical size [Vector2D: x: 800, y: 330] (mm)
DEBUG from aquamarine ]: drm: Description AOC CU34G4 2SER7HA005323 (DP-3)
DEBUG from aquamarine ]: drm: connector DP-3 crtc is incapable of vrr: props.vrr_capable -> 0, crtc->props.vrr_enabled -> 0
DEBUG from aquamarine ]: drm: Explicit sync unsupported
DEBUG from aquamarine ]: drm: connector DP-3 crtc supports CTM
DEBUG from aquamarine ]: drm: connector DP-3 crtc doesn't support HDR (0)
DEBUG from aquamarine ]: drm: connector DP-3 crtc doesn't support Colorspace (0)
DEBUG from aquamarine ]: drm: gpu /dev/dri/card0 becomes primary drm
DEBUG from aquamarine ]: DRM Dumb: created a dumb allocator
DEBUG from aquamarine ]: Starting the Aquamarine backend!
DEBUG from aquamarine ]: Starting the Wayland backend!
ERR from aquamarine ]: Wayland backend cannot start: wl_display_connect failed (is a wayland compositor running?)
ERR from aquamarine ]: Requested backend (wayland) could not start, enabling fallbacks
ERR from aquamarine ]: Implementation wayland failed, erasing.

The important part here is the one all the way at the back:

Code: Select all

 DEBUG from aquamarine ]: Starting the Aquamarine backend!
DEBUG from aquamarine ]: Starting the Wayland backend!
ERR from aquamarine ]: Wayland backend cannot start: wl_display_connect failed (is a wayland compositor running?)
ERR from aquamarine ]: Requested backend (wayland) could not start, enabling fallbacks
ERR from aquamarine ]: Implementation wayland failed, erasing.

I looked online for fixes and found that its most likely a mesa issue. But all the posts talking about it were from 2024 and recommendeusing mesa versions from that time, which iam pretty against and i believe there is a better fix. I already tried rebuilding both mesa and hyprland, i rebuild my whole system using —empty-tree and i updated hyprland to the newest version. Iam using nouveau with nvk and zink as iam on a musl/llvm profile and use a nvidia gpu.

GDH-gentoo · Post by **GDH-gentoo** » Sat Mar 14, 2026 4:42 pm

Nima0908 wrote:

Code: Select all

 --------------------------------------------
   Hyprland Crash Report
--------------------------------------------
Oops

Hyprland received signal 11(unknown)

That looks like a segmentation fault. No related logs in the output of dmesg?

Nima0908 · Post by **Nima0908** » Sat Mar 14, 2026 4:55 pm

Aww, i thought i was smart for once

. Indeed, there are logs in dmesg after trying to start hyprland. Here is the output:

Code: Select all

 LELII
L
LEI
LIIILLLCLLLL
LEIEL
4.7839011
nouveau
0000:01:00.0: [drm] fb0: nouveaudrmfb frame buffer device
4.8038761
nouveau
0000:01:00.0:
drm: Disabling PCI power management to avoid bug
4.8109011
nouveau
0000:01
:00.0:
gsp: cli:@xc1d00001 obj:0x00730000 ctrl cmd:0x00731341 failed: 0x000@ffff
4.810904]
nouveau
0000:01
:00.0:
Ldrm] *ERROR* DP-3: invalid native reply 0x03
4.8167651
nouveau
4.8167671
0000:01:00.0:
gsp: cli:0xc1d00001
obj: 0x00730000
ctrl cmd:0x00731341 failed: 0x0000ffff
nouveau
0000:01:00.0:
4. 822622]
nouveau
0000:01:00.0:
[drm] *ERROR* DP-3:
invalid native
reply 0x03
gsp: cli:0xc1d00001
4.8226231
nouveau
0000:01:00.0:
[drm] *ERROR* DP-3:
obj:0x00730000
ctrl cd:0x00731341 failed: 0x0000ffff
invalid native
reply Bx03
4.829009]
nouveau
4.829011]
0000:01:00.0:
gsp: cli:0xcld00001
obj:@x00730000
ctrl cmd:0x00731341 failed: 0x0000ffff
nouveau
0000:01:00.0:
[drm] *ERROR* DP-3:
invalid native
reply 8x03
4.
8339431
nouveau
0000:01:00.0:
gsp: cli:@xc1d00001
obj: 0x00730000
ctrl cd:0x00731341 failed: 0x0000ffff
4.8339451
nouveau
0000:01:00
0: [drm] *ERROR* DP-3:
invalid native
4.839795]
nouveau
0000:01:00.0:
gsp: cli:@xc1d00001
obj:0x00730000
reply
0x03
ctrl cmd:0x00731341 failed: 0x0000ffff
4
I. 8397971
nouveau
0000:01:00.0:
[drm] *ERROR* DP-3:
invalid native
reply
0x03
4.845625]
nouveau
0000:01:00.0:
4.8456271
nouveau
0000:01:00.0:
gsp: cli:@xc1d00001
obj: 0x00730000
ctrl cmd:0x00731341 failed: 0x0000ffff
[drm] *ERROR* DP-3:
invalid native
reply 8x03
4.851956]
nouveau
0000:01:00.0:
gsp: cli:@xc1d00001
4.8519571
nouveau
0000:01
:00.0:
[drm] *ERROR* DP-3:
obj:000730000
ctr1 cmd:0x00731341 failed: 0x0000ffff
invalid native
reply 8x03
15.6358761
nouveau
0000:01:00.0
gsp: cli:Bxc1d00001
obj:0x00730000 ctrl cmd:@x00731341 falled: 0xB000ffff
15.635880]
nouveau
0000:01:00.0:
[drm] *ERROR* DP-3: invalid native reply BxØ3
15.6431091
nouveau
0000:01:00.0:
gsp: cli:@xc1d00001
obj: 0x00730000
ctrl cmd:0x00731341 failed: 0x0000ffff
reply
0x03
15.6431121
nouveau
0000:01:00.0:
[drm] *ERROR* DP-3:
invalid native
15.6501023
nouveau
0000:01
:00.0:
gsp: cli:0xc1d00001
obj: 0x00730000
ctrl cmd:0x00731341 failed: 0x0000ffff
15.6501041
nouveau
0000:01:00
D：
[drm] *ERROR* DP-3:
invalid native
reply 0x03
15.6579443
nouveau
0000:01:00.0:
gsp: cli:0xc1d00001
obj: x00730000
ctrl cmd:0x00731341 failed: 0x0000ffff
15.6579461
nouveau
0000:01:00.0: [drm] *ERROR* DP-3:
invalid native
reply 8x83
15.6653531
nouveau
0000:01:00.0: gsp: cli: 0xc1d00001
obj: 0x00730000 ctrl cd:0x00731341 failed: 0x000@ffff
15.6653561
nouveau
0000:01:00.0: [drm] *ERROR* DP-3:
invalid native reply @x83
15.672720]
nouveau
0000:01:00.0: gsp: cli:0xc1d00001
obj: 0x00738800 ctrl cmd:@x00731341 failed: Bx0000ffff
15.6727223
nouveau
0000:01:00.0:
[drm] *ERROR* DP-3:
invalid native
reply 8x63
15.6798983
nouveau
0000:01:00.0: gsp: cli: Bxc1d00001
obj: 0x00730000
ctrl cd:0x00731341 failed: 0x0000ffff
15.6799001
nouveau
0000:01:00.0:
[drm] *ERROR* DP-3:
invalid native reply üxü3
15.687820]
nouveau
0000:01:00.0: gsp: cli:0xc1d00001
obj: 8x08730008
ctrl cmd:0x00731341 falled: 0x0000ffff
15.687821]
nouveau
0000:01:00.0:
[drm] *ERROR* DP-3:
invalid native reply 0x03
15.693191]
nouveau
0000:01:00.0: gsp: cli:@xc1d00001
obj:0x00730000 ctrl cd:0x00731341 falled: 0x0000ffff
15.693193]
nouveau
0000:01:00.0:
[drm] *ERROR* DP-3:
invalid native reply Øx83
15.700377)
nouveau
0000:01:00.0: gsp: cli:0xc1d00001
obj: 0x00730000
ctrl cmd:0x00731341 falled: 0x0000ffff
LLLL
15.7003793
nouveau
0000:01:00.0：
[drm] *ERROR* DP-3:
invalid native reply 0x03
15.7075921
nouveau
0000:01:00.0: gsp: cli:0xc1d00001
obj:@xB0730008ctrl cmd:Bx00731341 failed: Bx000@ffff
15.7075931
nouveau
0000:01:00.0: [drm] *ERROR* DP-3:
invalid native reply 0x03
15.7154361
nouveau
0000:01:00.0: gsp: cli:0xc1d00001
obj: ctrl cd:@x00731341 failed: @x000@ffff
[15.715438
nouveau
BB00:01:00.0: [drm] *ERROR* DP-3: invalid native reply 0x03

Sorry for this horendously bad formatted logs. I needed to copy them out of the picture as 0x0 somehow broke for me at the worst moment.

GDH-gentoo · Post by **GDH-gentoo** » Sat Mar 14, 2026 7:15 pm

Those are from the nouveau driver. Isn't there any about a segmentation fault in some Hyprland component?

Nima0908 · Post by **Nima0908** » Sat Mar 14, 2026 7:57 pm

No, sadly not. These are the only ones even closely related (they happen all the time after starting hyprland)

Post by Hu » Sat Mar 14, 2026 9:58 pm

Since this is reproducible, I suggest that you build hyprland with debug symbols, then reproduce the crash and collect a backtrace from the crashed process.

Nima0908 · Post by **Nima0908** » Sun Mar 15, 2026 10:41 am

Thanks for your answer. I now build it with debug symbols and -O0 and got a trace through strace (i wanted to use gdb and bt full, but as its not „crashing“ in the way hyprland thinks about it, no trace is being generated sadly. I searched through the trace and found a bunch of ENOENT, EACCES, EPERM and SIGSEGV but none of. them seems to be related to this crash.

trace.log:
https://0x0.st/PL24.log

Iam not to knowledgen in working with traces, so i dont really know what else i can look out for.

Post by Hu » Sun Mar 15, 2026 1:52 pm

-O0 is not necessary (though it can make some backtraces easier to read), and has been known to break some programs that rely on optimization.

I see in your strace that a process receives a SIGSEGV, which is definitely a crash, and it appears to be a null pointer dereference:

Code: Select all

9999  --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=NULL} ---

A debugger can trap on this before Hyprland intercepts it and discards the useful context. You could also check whether Hyprland has an option to disable this counterproductive interception, and allow the SIGSEGV to be delivered and generate a standard core file.

GDH-gentoo · Post by **GDH-gentoo** » Sun Mar 15, 2026 3:17 pm

Yeah, there's definitely a segmentation fault.

Code: Select all

9999  execve("/usr/bin/Hyprland", ["Hyprland", "--watchdog-fd", "4"], 0x7ffd3c919408 /* 27 vars */) = 0

Process 9999 executes the Hyprland program.

Nima0908, could you post the content of file ~/.cache/hyprland/hyprlandCrashReport9999.txt that, according to your strace, has been produced as a result?

Maybe there are other such files from previous crashes.

Nima0908 · Post by **Nima0908** » Tue Mar 17, 2026 5:11 pm

Thanks for all your answsers. First of all, here is the 9999 crashreport:

Code: Select all

 --------------------------------------------
   Hyprland Crash Report
--------------------------------------------
All these computers...

Hyprland received signal 11(unknown)
Version: 59f9f2688ac508a0584d1462151195a6c4992f99
Tag: v0.54.2
Date: Tue Mar 10 13:26:58 2026
Flags:
no xwayland

System info:
	System name: Linux
	Node name: gentoo
	Release: 6.18.12-gentoo
	Version: #5 SMP PREEMPT Mon Mar  9 18:57:08 CET 2026

GPU:
	01:00.0 VGA compatible controller [0300]: NVIDIA Corporation AD107 [GeForce RTX 4060] [10de:2882] (rev a1) (prog-if 00 [VGA controller])


os-release:
	NAME=Gentoo
	ID=gentoo
	PRETTY_NAME="Gentoo Linux"
	ANSI_COLOR="1;32"
	HOME_URL="https://www.gentoo.org/"
	SUPPORT_URL="https://www.gentoo.org/support/"
	BUG_REPORT_URL="https://bugs.gentoo.org/"
	VERSION_ID="2.18"

Libraries:
Hyprgraphics: built against 0.5.0, system has 0.5.0
Hyprutils: built against 0.11.0, system has 0.11.0
Hyprcursor: built against 0.1.13, system has 0.1.13
Hyprlang: built against 0.6.8, system has 0.6.8
Aquamarine: built against 0.10.0, system has 0.10.0

Backtrace:
	# | configuration does not support execinfo.h
		??
		??:0


Log tail:
DEBUG from aquamarine ]: drm: Skipping connector DP-3, has crtc 67 and is connected
DEBUG from aquamarine ]: drm: slot 0 crtc 67 taken by DP-3, skipping
DEBUG from aquamarine ]: drm: slot 1 crtc 82 unassigned
DEBUG from aquamarine ]: drm: slot 2 crtc 97 unassigned
DEBUG from aquamarine ]: drm: slot 3 crtc 112 unassigned
DEBUG from aquamarine ]: drm: Connector DP-1 is not connected
DEBUG from aquamarine ]: drm: Connector DP-2 is not connected
DEBUG from aquamarine ]: drm: Connector HDMI-A-1 is not connected
DEBUG from aquamarine ]: drm: Connector DP-3 connected
DEBUG from aquamarine ]: drm: Connecting connector DP-3, CRTC ID 67
DEBUG from aquamarine ]: drm: Dumping detected modes:
DEBUG from aquamarine ]: drm: Mode 0: 3440x1440@60.00Hz  (preferred)
DEBUG from aquamarine ]: drm: Mode 1: 3440x1440@100.00Hz 
DEBUG from aquamarine ]: drm: Mode 2: 3440x1440@75.00Hz 
DEBUG from aquamarine ]: drm: Mode 3: 3440x1440@30.00Hz 
DEBUG from aquamarine ]: drm: Mode 4: 2560x1440@120.00Hz 
DEBUG from aquamarine ]: drm: Mode 5: 2560x1080@60.00Hz 
DEBUG from aquamarine ]: drm: Mode 6: 2560x1080@59.94Hz 
DEBUG from aquamarine ]: drm: Mode 7: 2560x1080@50.00Hz 
DEBUG from aquamarine ]: drm: Mode 8: 1920x1080@120.00Hz 
DEBUG from aquamarine ]: drm: Mode 9: 1920x1080@119.88Hz 
DEBUG from aquamarine ]: drm: Mode 10: 1920x1080@60.00Hz 
DEBUG from aquamarine ]: drm: Mode 11: 1920x1080@60.00Hz 
DEBUG from aquamarine ]: drm: Mode 12: 1920x1080@59.94Hz 
DEBUG from aquamarine ]: drm: Mode 13: 1920x1080@50.00Hz 
DEBUG from aquamarine ]: drm: Mode 14: 1680x1050@59.95Hz 
DEBUG from aquamarine ]: drm: Mode 15: 1280x1024@75.03Hz 
DEBUG from aquamarine ]: drm: Mode 16: 1280x1024@60.02Hz 
DEBUG from aquamarine ]: drm: Mode 17: 1440x900@59.89Hz 
DEBUG from aquamarine ]: drm: Mode 18: 1280x720@60.00Hz 
DEBUG from aquamarine ]: drm: Mode 19: 1280x720@59.94Hz 
DEBUG from aquamarine ]: drm: Mode 20: 1280x720@50.00Hz 
DEBUG from aquamarine ]: drm: Mode 21: 1024x768@99.99Hz 
DEBUG from aquamarine ]: drm: Mode 22: 1024x768@75.03Hz 
DEBUG from aquamarine ]: drm: Mode 23: 1024x768@70.07Hz 
DEBUG from aquamarine ]: drm: Mode 24: 1024x768@60.00Hz 
DEBUG from aquamarine ]: drm: Mode 25: 832x624@74.55Hz 
DEBUG from aquamarine ]: drm: Mode 26: 800x600@99.86Hz 
DEBUG from aquamarine ]: drm: Mode 27: 800x600@75.00Hz 
DEBUG from aquamarine ]: drm: Mode 28: 800x600@72.19Hz 
DEBUG from aquamarine ]: drm: Mode 29: 800x600@60.32Hz 
DEBUG from aquamarine ]: drm: Mode 30: 800x600@56.25Hz 
DEBUG from aquamarine ]: drm: Mode 31: 720x576@50.00Hz 
DEBUG from aquamarine ]: drm: Mode 32: 720x480@60.00Hz 
DEBUG from aquamarine ]: drm: Mode 33: 720x480@59.94Hz 
DEBUG from aquamarine ]: drm: Mode 34: 640x480@99.83Hz 
DEBUG from aquamarine ]: drm: Mode 35: 640x480@75.00Hz 
DEBUG from aquamarine ]: drm: Mode 36: 640x480@72.81Hz 
DEBUG from aquamarine ]: drm: Mode 37: 640x480@66.67Hz 
DEBUG from aquamarine ]: drm: Mode 38: 640x480@60.00Hz 
DEBUG from aquamarine ]: drm: Mode 39: 640x480@59.94Hz 
DEBUG from aquamarine ]: drm: Mode 40: 720x400@70.08Hz 
DEBUG from aquamarine ]: drm: Physical size [Vector2D: x: 800, y: 330] (mm)
DEBUG from aquamarine ]: drm: Description AOC CU34G4 2SER7HA005323 (DP-3)
DEBUG from aquamarine ]: drm: connector DP-3 crtc is incapable of vrr: props.vrr_capable -> 0, crtc->props.vrr_enabled -> 0
DEBUG from aquamarine ]: drm: Explicit sync unsupported
DEBUG from aquamarine ]: drm: connector DP-3 crtc supports CTM
DEBUG from aquamarine ]: drm: connector DP-3 crtc doesn't support HDR (0)
DEBUG from aquamarine ]: drm: connector DP-3 crtc doesn't support Colorspace (0)
DEBUG from aquamarine ]: drm: gpu /dev/dri/card0 becomes primary drm
DEBUG from aquamarine ]: DRM Dumb: created a dumb allocator
DEBUG from aquamarine ]: Starting the Aquamarine backend!
DEBUG from aquamarine ]: Starting the Wayland backend!
ERR from aquamarine ]: Wayland backend cannot start: wl_display_connect failed (is a wayland compositor running?)
ERR from aquamarine ]: Requested backend (wayland) could not start, enabling fallbacks
ERR from aquamarine ]: Implementation wayland failed, erasing.

Yes, there are other files for each crash, i postet one in the main question. Ive tried now multiple ways to get hyprland to not discard all the context after the SIGSEGV and to catch the programm after the SIGSEGV in gdb (for example through handle SIGSEGV stop print pass) but to no results, it still exits cleanely after the crash. As far as i know and as far as i read it in the docs, hyprland doesnt seem to have a option for that too.

Sorry for the late response, i had a lot of stuff to do irl yesterday.

Post by Hu » Tue Mar 17, 2026 6:21 pm

By default, the debugger should automatically trap on a SIGSEGV when the kernel delivers one to the inferior. Some minor signals are ignored by default, but SIGSEGV is not minor.

That text file does not look useful to me. Perhaps it will be of help to a Hyprland developer. Otherwise, you need to get a proper core dump and backtrace.

GDH-gentoo · Post by **GDH-gentoo** » Wed Mar 18, 2026 3:28 am

Hu wrote:By default, the debugger should automatically trap on a SIGSEGV when the kernel delivers one to the inferior. Some minor signals are ignored by default, but SIGSEGV is not minor.

Would that happen if Hyprland installs a signal handler for SIGSEGV?

Nima0908 wrote:https://0x0.st/PL24.log

Code: Select all

9999  rt_sigaction(SIGSEGV, {sa_handler=0x55f385cae6d0, sa_mask=[], sa_flags=SA_RESTORER|SA_RESTART, sa_restorer=0x7fdf365baeb9}, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=0}, 8) = 0

src/Compositor.hpp

Code: Select all

class CCompositor {
  public:
    // ...
    void                                         initServer(std::string socketName, int socketFd);
    // ...
};

src/Compositor.cpp

Code: Select all

void CCompositor::initServer(std::string socketName, int socketFd) {
    // ...
    if (!Env::envEnabled("HYPRLAND_NO_CRASHREPORTER")) {
        signal(SIGSEGV, handleUnrecoverableSignal);
        signal(SIGABRT, handleUnrecoverableSignal);
    }
    // ...
}

From the code, however, it looks like setting environment variable HYPRLAND_NO_CRASHREPORTER to 1 avoids this, so the SIGSEGV would then kill the Hypland process.

With respect to getting a backtrace, it complicates things that, judging from the output of strace, the long lived Hypland process that segfaults runs as a child of start-hyprland (and it spawns two short-lived Hypland processes before that), so I suppose that, e. g., using GDB, one would have to use:

Code: Select all

set environment HYPRLAND_NO_CRASHREPORTER = 1

or otherwise use catch signal SIGSEGV to set a catchpoint.

Code: Select all

set follow-fork-mode child

to have GDB debug the child process after a fork() call.

Code: Select all

set detach-on-fork off

so that the parent is held suspended instead of detached while GDB follows the child, so if it is a child that exits, one can return to the parent using the inferior and continue commands.

I'd recommend building Hyprland, Aquamarine and Mesa with debug symbols, because one of the last system calls that Hyprland did before the segfault was a read() for loading the Nouveau Vulkan driver (libvulkan_nouveau.so)

Post by Hu » Wed Mar 18, 2026 1:35 pm

GDH-gentoo wrote:
Hu wrote:By default, the debugger should automatically trap on a SIGSEGV when the kernel delivers one to the inferior. Some minor signals are ignored by default, but SIGSEGV is not minor.
Would that happen if Hyprland installs a signal handler for SIGSEGV?

I was not able to find a definitive statement on this in info gdb, but my understanding is that if a process being supervised by ptrace receives a signal, then the ptrace supervisor will be notified before the kernel does anything with delivering the signal to the target process. The supervisor then has the option to resume the inferior, and either deliver the signal or not, as the supervisor chooses.

Per man ptrace:

Code: Select all

       While being traced, the tracee will stop each time a signal  is  deliv‐
       ered,  even  if the signal is being ignored.  (An exception is SIGKILL,
       which has its usual effect.)  The tracer will be notified at  its  next
       call  to  waitpid(2)  (or one of the related "wait" system calls); that
       call will return a status value containing information  that  indicates
       the  cause of the stop in the tracee.  While the tracee is stopped, the
       tracer can use various ptrace operations  to  inspect  and  modify  the
       tracee.   The tracer then causes the tracee to continue, optionally ig‐
       noring the delivered signal (or even delivering a different signal  in‐
       stead).

My guess is that OP has the wrong process as the inferior, due to the fork/exec behavior you described, and thus the inferior under debugging never receives any signals (handled or unhandled), so there is nothing for gdb to trap in that inferior.

Nima0908 · Post by **Nima0908** » Thu Mar 19, 2026 6:37 pm

Sorry for the late answer, i had to fix my pc not booting at all after a update.

Code: Select all

set environment HYPRLAND_NO_CRASHREPORTER = 1

does absolutely nothing. Even if i set it directly in a tty using export and run start-hyprland there it doesnt change a thing. Following the childprocess (in this case the hyprland command) reveals that if i switch to inferior 2 (Which is hyprland) and continue, it runs cleanely forever and doesnt crash somehow (i let it run for 5 min). I didnt bother to test inferior 3 though as its just bash and it works fine otherwise i couldnt use the tty

. Inferior 1 gets the same results as all the other times (still crash, its start-hyprland). The only bt i get is the one after manually killing of inferior 2 after letting it run for 5min, so thats not really usefull. Also, ive already build it with -g (i doublechecked), so it should be built with debug symbols already (atleast emerge --info gui-wm/hyprland says so).

Nima0908 · Post by **Nima0908** » Thu Mar 19, 2026 10:37 pm

This may not be really usefull, but i just remembered i had a simmilar issue a year ago with kicad. When compilling it with clang, i always got a SIGSEGV, but running ingdb it was fine and never recieved a SIGSEGV. I only had this issue with clang back then and recompilling with gcc fixed it, but iam not sure if its the same here and i really want a clang only system without gcc. Maybe i can test out my theory tomorrow.

GDH-gentoo · Post by **GDH-gentoo** » Fri Mar 20, 2026 12:48 pm

Nima0908 wrote:Even if i set it directly in a tty using export and run start-hyprland there it doesnt change a thing.

The idea is that, if Hyprland still crashes, instead of letting it catch the SIGSEGV signal, create a text file in ~/.cache/hyprland and exit semi-gracefully, it lets the signal kill the process, so that you might have e. g. traces of the segfault in the output of dmesg, or a backtrace in GDB (if you manage to debug the correct process while the rest continue running), with better information.

Is there anything in dmesg with:

Code: Select all

$ export HYPRLAND_NO_CRASHREPORTER=1
$ start-hyprland

(assuming that it still crashes)?

Another thing you can try is running Hyprland directly with GDB (again, with set environment HYPRLAND_NO_CRASHREPORTER = 1), without start-hyprland, to avoid having to deal with debugging multiple processes with multiple inferiors. Looking at the code, it seems like you'll get a "WARNING: Hyprland is being launched without start-hyprland. This is highly advised against." complaint, but it should run regardless.

Nima0908 · Post by **Nima0908** » Fri Mar 20, 2026 4:22 pm

Thanks for your answer. Sadly, the only thing that

Code: Select all

HYPRLAND_NO_CRASHREPORTER=1

does is remove the crash report completely, which is not really helpfull, especially as this is the only thing it does. I decided to rebuild hyprland with a sanitizer also to get some more information about what could be causing it and i got the following:

Code: Select all

=================================================================
==72380==ERROR: AddressSanitizer: container-overflow on address 0x7bd4b0d3b620 at pc 0x55f14f37d386 bp 0x7ffd32015110 sp 0x7ffd32015108
READ of size 4 at 0x7bd4b0d3b620 thread T0
    #0 0x55f14f37d385  (/usr/bin/Hyprland+0x1f82385)
    #1 0x55f14f37ce34  (/usr/bin/Hyprland+0x1f81e34)
    #2 0x55f14f37e924  (/usr/bin/Hyprland+0x1f83924)
    #3 0x7f14b4c6279c  (/lib/libaquamarine.so.9+0xbf79c)
    #4 0x7f14b4c5af31  (/lib/libaquamarine.so.9+0xb7f31)
    #5 0x7f14b4c5c153  (/lib/libaquamarine.so.9+0xb9153)
    #6 0x7f14b4c2fa91  (/lib/libaquamarine.so.9+0x8ca91)
    #7 0x55f14deb3bf3  (/usr/bin/Hyprland+0xab8bf3)
    #8 0x55f14de842bd  (/usr/bin/Hyprland+0xa892bd)

0x7bd4b0d3b620 is located 96 bytes inside of 128-byte region [0x7bd4b0d3b5c0,0x7bd4b0d3b640)
allocated by thread T0 here:
    #0 0x55f14de812cd  (/usr/bin/Hyprland+0xa862cd)
    #1 0x55f14f37cb8d  (/usr/bin/Hyprland+0x1f81b8d)

HINT: if you don't care about these errors you may set ASAN_OPTIONS=detect_container_overflow=0.
If you suspect a false positive see also: https://github.com/google/sanitizers/wiki/AddressSanitizerContainerOverflow.
SUMMARY: AddressSanitizer: container-overflow (/usr/bin/Hyprland+0x1f82385) 
Shadow bytes around the buggy address:
  0x7bd4b0d3b380: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fa
  0x7bd4b0d3b400: fa fa fa fa fa fa fa fa fd fd fd fd fd fd fd fd
  0x7bd4b0d3b480: fd fd fd fd fd fd fd fa fa fa fa fa fa fa fa fa
  0x7bd4b0d3b500: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fa
  0x7bd4b0d3b580: fa fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00
=>0x7bd4b0d3b600: 00 00 00 00[fc]fc fc fc fa fa fa fa fa fa fa fa
  0x7bd4b0d3b680: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x7bd4b0d3b700: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x7bd4b0d3b780: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x7bd4b0d3b800: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x7bd4b0d3b880: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:       fa
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
==72380==ABORTING

=================================================================
==72375==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 16 byte(s) in 2 object(s) allocated from:
    #0 0x55a6a2cb79ad in strdup (/usr/bin/start-hyprland+0x18a9ad)
    #1 0x55a6a2d16ce5 in CHyprlandInstance::runHyprlandThread(bool) (/usr/bin/start-hyprland+0x1e9ce5)
    #2 0x55a6a2d1827e in CHyprlandInstance::run(bool) (/usr/bin/start-hyprland+0x1eb27e)
    #3 0x55a6a2d705d0 in main (/usr/bin/start-hyprland+0x2435d0)
    #4 0x7efd13c5bda9  (/lib/ld-musl-x86_64.so.1+0x55da9)

Direct leak of 9 byte(s) in 1 object(s) allocated from:
    #0 0x55a6a2cb79ad in strdup (/usr/bin/start-hyprland+0x18a9ad)
    #1 0x55a6a2d16b7b in CHyprlandInstance::runHyprlandThread(bool) (/usr/bin/start-hyprland+0x1e9b7b)
    #2 0x55a6a2d1827e in CHyprlandInstance::run(bool) (/usr/bin/start-hyprland+0x1eb27e)
    #3 0x55a6a2d705d0 in main (/usr/bin/start-hyprland+0x2435d0)
    #4 0x7efd13c5bda9  (/lib/ld-musl-x86_64.so.1+0x55da9)

SUMMARY: AddressSanitizer: 25 byte(s) leaked in 3 allocation(s).

Not too sure if this even helps though.

Nima0908 · Post by **Nima0908** » Fri Mar 20, 2026 6:01 pm

Alright, i made some progress. I was annoyed that hyprland didnt work and decided to use another one one. Turns out this one also doesnt work and fails with a segfault. And guess what, i actually get dmesg logs this time, yay

. So turns out the segfault isnt even the fault of the wm, but it seems to be on nouveau`s side. Here is the output of dmesg confirming it:

Code: Select all

 [  284.676172] nouveau 0000:01:00.0: gsp: cli:0xc1d00001 obj:0x00730000 ctrl cmd:0x00731341 failed: 0x0000ffff
[  284.676176] nouveau 0000:01:00.0: [drm] *ERROR* DP-3: invalid native reply 0x03
[  284.683934] nouveau 0000:01:00.0: gsp: cli:0xc1d00001 obj:0x00730000 ctrl cmd:0x00731341 failed: 0x0000ffff
[  284.683936] nouveau 0000:01:00.0: [drm] *ERROR* DP-3: invalid native reply 0x03
[  284.691483] nouveau 0000:01:00.0: gsp: cli:0xc1d00001 obj:0x00730000 ctrl cmd:0x00731341 failed: 0x0000ffff
[  284.691485] nouveau 0000:01:00.0: [drm] *ERROR* DP-3: invalid native reply 0x03
[  284.699704] nouveau 0000:01:00.0: gsp: cli:0xc1d00001 obj:0x00730000 ctrl cmd:0x00731341 failed: 0x0000ffff
[  284.699705] nouveau 0000:01:00.0: [drm] *ERROR* DP-3: invalid native reply 0x03
[  284.706212] nouveau 0000:01:00.0: gsp: cli:0xc1d00001 obj:0x00730000 ctrl cmd:0x00731341 failed: 0x0000ffff
[  284.706213] nouveau 0000:01:00.0: [drm] *ERROR* DP-3: invalid native reply 0x03
[  284.713558] nouveau 0000:01:00.0: gsp: cli:0xc1d00001 obj:0x00730000 ctrl cmd:0x00731341 failed: 0x0000ffff
[  284.713559] nouveau 0000:01:00.0: [drm] *ERROR* DP-3: invalid native reply 0x03
[  284.721128] nouveau 0000:01:00.0: gsp: cli:0xc1d00001 obj:0x00730000 ctrl cmd:0x00731341 failed: 0x0000ffff
[  284.721129] nouveau 0000:01:00.0: [drm] *ERROR* DP-3: invalid native reply 0x03
[  284.729396] nouveau 0000:01:00.0: gsp: cli:0xc1d00001 obj:0x00730000 ctrl cmd:0x00731341 failed: 0x0000ffff
[  284.729397] nouveau 0000:01:00.0: [drm] *ERROR* DP-3: invalid native reply 0x03
[  289.365911] nouveau 0000:01:00.0: gsp: cli:0xc1d00001 obj:0x00730000 ctrl cmd:0x00731341 failed: 0x0000ffff
[  289.365914] nouveau 0000:01:00.0: [drm] *ERROR* DP-3: invalid native reply 0x03
[  289.373574] nouveau 0000:01:00.0: gsp: cli:0xc1d00001 obj:0x00730000 ctrl cmd:0x00731341 failed: 0x0000ffff
[  289.373576] nouveau 0000:01:00.0: [drm] *ERROR* DP-3: invalid native reply 0x03
[  289.381181] nouveau 0000:01:00.0: gsp: cli:0xc1d00001 obj:0x00730000 ctrl cmd:0x00731341 failed: 0x0000ffff
[  289.381183] nouveau 0000:01:00.0: [drm] *ERROR* DP-3: invalid native reply 0x03
[  289.389146] nouveau 0000:01:00.0: gsp: cli:0xc1d00001 obj:0x00730000 ctrl cmd:0x00731341 failed: 0x0000ffff
[  289.389147] nouveau 0000:01:00.0: [drm] *ERROR* DP-3: invalid native reply 0x03
[  289.394672] nouveau 0000:01:00.0: gsp: cli:0xc1d00001 obj:0x00730000 ctrl cmd:0x00731341 failed: 0x0000ffff
[  289.394674] nouveau 0000:01:00.0: [drm] *ERROR* DP-3: invalid native reply 0x03
[  289.402464] nouveau 0000:01:00.0: gsp: cli:0xc1d00001 obj:0x00730000 ctrl cmd:0x00731341 failed: 0x0000ffff
[  289.402465] nouveau 0000:01:00.0: [drm] *ERROR* DP-3: invalid native reply 0x03
[  289.410035] nouveau 0000:01:00.0: gsp: cli:0xc1d00001 obj:0x00730000 ctrl cmd:0x00731341 failed: 0x0000ffff
[  289.410036] nouveau 0000:01:00.0: [drm] *ERROR* DP-3: invalid native reply 0x03
[  289.417993] nouveau 0000:01:00.0: gsp: cli:0xc1d00001 obj:0x00730000 ctrl cmd:0x00731341 failed: 0x0000ffff
[  289.417994] nouveau 0000:01:00.0: [drm] *ERROR* DP-3: invalid native reply 0x03
[ 1303.945024] niri[65121]: segfault at 0 ip 00007f1a88cce7e0 sp 00007ffdf3ac25d0 error 4 in libvulkan_nouveau.so[ecd7e0,7f1a886ee000+610000] likely on CPU 6 (core 2, socket 0)
[ 1303.945034] Code: 8b 05 f4 7b 0a 00 eb 22 66 90 4a 8b 34 30 48 83 c6 08 ba 08 00 00 00 48 89 df e8 9f 6f 02 00 48 8b 05 d4 7b 0a 00 49 83 c6 10 <4a> 8b 4c 30 f8 48 83 f9 19 74 d5 48 85 c9 75 ec 48 8b 44 24 08 48
[ 1382.333368] niri[114350]: segfault at 0 ip 00007f63526ce7e0 sp 00007ffd949c94e0 error 4 in libvulkan_nouveau.so[ecd7e0,7f63520ee000+610000] likely on CPU 6 (core 2, socket 0)
[ 1382.333379] Code: 8b 05 f4 7b 0a 00 eb 22 66 90 4a 8b 34 30 48 83 c6 08 ba 08 00 00 00 48 89 df e8 9f 6f 02 00 48 8b 05 d4 7b 0a 00 49 83 c6 10 <4a> 8b 4c 30 f8 48 83 f9 19 74 d5 48 85 c9 75 ec 48 8b 44 24 08 48
[ 1592.371916] niri[147065]: segfault at 0 ip 00007fa0916ce7e0 sp 00007fff58b3c6b0 error 4 in libvulkan_nouveau.so[ecd7e0,7fa0910ee000+610000] likely on CPU 5 (core 1, socket 0)
[ 1592.371924] Code: 8b 05 f4 7b 0a 00 eb 22 66 90 4a 8b 34 30 48 83 c6 08 ba 08 00 00 00 48 89 df e8 9f 6f 02 00 48 8b 05 d4 7b 0a 00 49 83 c6 10 <4a> 8b 4c 30 f8 48 83 f9 19 74 d5 48 85 c9 75 ec 48 8b 44 24 08 48
[ 1877.886359] niri[158492]: segfault at 0 ip 00007f0e536d8d30 sp 00007ffecf3c68a0 error 4 in libvulkan_nouveau.so[ed7d30,7f0e530f3000+61b000] likely on CPU 7 (core 3, socket 0)
[ 1877.886370] Code: 8b 05 34 d3 0a 00 eb 22 66 90 4a 8b 34 30 48 83 c6 08 ba 08 00 00 00 48 89 df e8 9f ad 02 00 48 8b 05 14 d3 0a 00 49 83 c6 10 <4a> 8b 4c 30 f8 48 83 f9 19 74 d5 48 85 c9 75 ec 48 8b 44 24 08 48

I hope this is still in the scope of this thread, even though it turned into a different direction and would fit more into the kernel section now. If this is an issue, please let me know and ill move it (if possible) or just open a new one over there and close this one

wjb · Post by **wjb** » Fri Mar 20, 2026 7:34 pm

Why not try with nvidia-drivers? I mean, if you have a 4060, why not use it?

Nima0908 · Post by **Nima0908** » Fri Mar 20, 2026 9:03 pm

Ah, i forgot to explain it, sorry. Iam on a llvm/musl setup and sadly, nvidia ships theire userspace driver only precompilled for the normal glibc, therefore its incompatible and i have to use the open source drivers. I was planning to use nova as it was and still is really hyped up but its far from being usable (doesnt even load), so i had to use nouveau

GDH-gentoo · Post by **GDH-gentoo** » Fri Mar 20, 2026 9:34 pm

Nima0908 wrote:

Code: Select all

[ 1877.886359] niri[158492]: segfault at 0 ip 00007f0e536d8d30 sp 00007ffecf3c68a0 error 4 in libvulkan_nouveau.so[ed7d30,7f0e530f3000+61b000] likely on CPU 7 (core 3, socket 0)
[ 1877.886370] Code: 8b 05 34 d3 0a 00 eb 22 66 90 4a 8b 34 30 48 83 c6 08 ba 08 00 00 00 48 89 df e8 9f ad 02 00 48 8b 05 14 d3 0a 00 49 83 c6 10 <4a> 8b 4c 30 f8 48 83 f9 19 74 d5 48 85 c9 75 ec 48 8b 44 24 08 48

This is Nouveau the Vulkan driver (from Mesa), not Nouveau the kernel driver... the "invalid native reply" error from the kernel driver may or may not be related, but the segfault is in the Vulkan driver.

Hyprland was also using it. From the output of strace:

Code: Select all

9999  execve("/usr/bin/Hyprland", ["Hyprland", "--watchdog-fd", "4"], 0x7ffd3c919408 /* 27 vars */) = 0
...
9999  open("/usr/lib/libvulkan_nouveau.so", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 37
...
9999  read(37, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\0\0\0\0\0\0\0\0"..., 960) = 960
...
9999  close(37)                         = 0

Nima0908 · Post by **Nima0908** » Sat Mar 21, 2026 5:27 pm

Yes, iam aware that this is the userspace implementation at the end thats causing the sigsegv. I was assuming that the sigsegv is caused by the kernel space drivers because of the errors above though, but iam not sure and i dont really know how to fix it as the only real clue i found was the exact same issue asked on a nixos forum and it never was answered, so i dont really know how to move forward. That said, i could technically boot up a livegui usb as it uses nouveau too and see if i get a simmilar issue there.

Nima0908 · Post by **Nima0908** » Sat Mar 21, 2026 6:09 pm

After further testing, i concluded that its probaply the mesa implementation and not the kernelspace one (i get the drm errors on the livegui too but its working over there just fine). Ill try to rebuild mesa without nvk and zink again, as iam suspecting that these are the parts that are causing the problems (atleast livegui wasnt using them)

Nima0908 · Post by **Nima0908** » Sat Mar 21, 2026 7:18 pm

Rebuilding mesa without zink and nvk indeed fixed it. Ill close this thread now, as the original purpose of the thread has been solved and the nouveau issues are outside of the scope of this thread.

[Solved] Hyprland crashes on startup

[Solved] Hyprland crashes on startup

Re: Hyprland crashes on startup