segfault when receiving notifications while screen is off (Wayland)

[9ary]

I use a DisplayPort monitor. These have the peculiar behavior of "disappearing" when they are turned off, as if you had unplugged the cable.

Consistent repro:

• start dunst in a terminal to catch the crash
• turn monitor off (or unplug it)
• send a notification with notify-send or something else
• turn monitor back on
• dunst has crashed

Installation info

• Version: Dunst - A customizable and lightweight notification-daemon 1.6.1 (2021-02-21)
• Install type: package
• Distro and version: Arch Linux (up to date)
• Wayland compositor: sway 1.6

[fwsmit]

Could you send the dunst debug logs?

[9ary]

It doesn't print anything at all, other than WARNING: No icon found in path: 'dialog-information', even after setting verbosity = debug. Am I missing something?

[9ary]

Nevermind, here it is: https://wank.party/Woc8.log

[fwsmit]

I think it's related to #877

[fwsmit]

@9ary I don't see any segfault in the logs. Maybe you didn't pipe the errors to the log file. Hint: dunst -verbosity debug > crash.log 2>&1

[9ary]

There was nothing on stderr, just the standard segfault message which would be at the very end.

[fwsmit]

What does the segfault message say?

[9ary]

Seems like even redirecting stderr doesn't push that message to the log file. This is the message:

zsh: segmentation fault (core dumped)  dunst -verbosity debug > dunst.log 2>&1

Here's another log for completeness: https://wank.party/YimJ.log

[fwsmit]

Thank you, I can reproduce it. What's probably happening is that when the monitor is off, dunst tries to create a window. That window is for some reason destroyed by the compositor. After that dunst comes in an infinite loop of requesting new windows (this is a know bug, see #877).
It should be possible to create a window when the monitor is off, though, so this is still a separate issue from #877.

[WhitePeter]

May I suggest a workaround?

dunstctl set-paused true or sending SIGUSR1 to the dunst process pauses processing of notification sending and queues the notifications until resumed by either dunstctl set-paused false or SIGUSR2. If you can hook this to turning off/on the monitor, then dunst should not segfault, when it is off, because it should wait until it is back on.

See MISCELLANEOUS in dunst(1) for reference.

[WhitePeter]

It should be possible to create a window when the monitor is off, though, so this is still a separate issue from #877.

I cannot reproduce this, because I do not have a DP monitor to test it with but @9ary said that it disappears entirely. When I send a notification while the display of my laptop is off, without suspending dunst, it does not crash.

BTW, it is good practice to pause dunst while the display is off or the session is suspended/locked because one might lose notifications otherwise, i.e.:
{sleep 5; notify-send -t 5000 Test}& loginctl lock-session
Wait more than 10 seconds and the notification is gone.

[9ary]

May I suggest a workaround?

dunstctl set-paused true or sending SIGUSR1 to the dunst process pauses processing of notification sending and queues the notifications until resumed by either dunstctl set-paused false or SIGUSR2. If you can hook this to turning off/on the monitor, then dunst should not segfault, when it is off, because it should wait until it is back on.

See MISCELLANEOUS in dunst(1) for reference.

That's not a bad idea actually, should be easy to do with kanshi. I think it might be a good idea to have this as an option in dunst.

[fwsmit]

@9ary I've added a fix for this crash. My method of reproducing was:
swaymsg output "*" disable && sleep 1 && notify-send "Crash Dunst" && sleep 1 && kanshi
Now dunst doesn't crash anymore from that.

[9ary]

Thanks, I'll try it out when I get the chance.