Running waybar via Hyprland exec-once doesn't work upon first try after startup

[Lauchmelder23]

When adding exec-once = waybar to the systems hyprland.conf, the waybar fails to start properly. Most of the times it doesn't start at all, sometimes it starts but with some of the plugins disabled (namely the workspace plugin). However, if one ends the Hyprland session and starts it again (without rebooting) the waybar starts properly. This only happens after the first Hyprland initialisation after boot.

For debugging I wrote waybar's output to a log file (exec-once = (waybar > ~/waybar.log 2>&1)), which resulted in:

[2025-01-14 17:15:22.510] [info] Using configuration file /home/robert/.config/waybar/config
[2025-01-14 17:15:22.643] [info] Using CSS file /home/robert/.config/waybar/style.css
[2025-01-14 17:15:22.648] [info] Hyprland IPC starting

To me this seems like waybar is hard crashing without even generating an error message. Sadly I don't have a log for the case where waybar partially starts, as that case is very rare. I have witnessed this issue on two separate machines running Arch + Hyprland.

System info
OS: Arch Linux x86_64
Kernel: 6.12.8-arch1-1
Window Manager: Hyprland

Package versions
Hyprland: 0.46.2-5
waybar: 0.11.0-5

[Lauchmelder23]

After compiling from source and running that version of waybar I was unable to reproduce the issue. Neither the current master nor the tag 0.11.0 experience the same problem. At first I suspected that 92242f0 fixed the issue already, but since it also doesnt occur with a self-compiled version 0.11.0 this doesnt seem to be the case.

[Lauchmelder23]

The plot is thickening: I have pulled the the waybar package repo (https://gitlab.archlinux.org/archlinux/packaging/packages/waybar) and built the package from the PKGBUILD, which should give me the same binary as the one installed via pacman, but the issue disappears when using the custom build. I disabled the check() inside PKGBUILD and disabled the tests flag, because I had issues linking with Catch on my system. However that shouldn't change anything.

So I guess this is an issue with the package and not inherent to waybar? Feel free to close the issue if you don't want to investigate further.

[TAforever]

same here, and this is happening not only on hyprland
https://gitlab.archlinux.org/archlinux/packaging/packages/waybar/-/issues/4

[Lauchmelder23]

I performed a backtrace on one of the coredumps and this is the result:

#0  std::char_traits<char>::assign (__c1=@0x7ec77c000f28: 0 '\000', __c2=<error reading variable: Cannot access memory at address 0x82cb4bc051b66be2>)
    at /usr/src/debug/gcc/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/char_traits.h:350
#1  std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_S_copy
    (__d=0x7ec77c000f28 "", __s=0x82cb4bc051b66be2 <error: Cannot access memory at address 0x82cb4bc051b66be2>, __n=1)
    at /usr/src/debug/gcc/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/basic_string.h:433
#2  std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_S_copy_chars
    (__p=0x7ec77c000f28 "", __k1=0x82cb4bc051b66be2 <error: Cannot access memory at address 0x82cb4bc051b66be2>, __k2=0x82cb4bc051b66be3 <error: Cannot access memory at address 0x82cb4bc051b66be3>) at /usr/src/debug/gcc/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/basic_string.h:483
#3  std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct<char*>
    (this=0x7ec77c000f18, __beg=0x82cb4bc051b66be2 <error: Cannot access memory at address 0x82cb4bc051b66be2>, __end=0x82cb4bc051b66be3 <error: Cannot access memory at address 0x82cb4bc051b66be3>) at /usr/src/debug/gcc/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/basic_string.tcc:247
#4  std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string (this=0x7ec77c000f18, __str=<error: Cannot access memory at address 0x82cb4bc051b66be2>)
    at /usr/src/debug/gcc/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/basic_string.h:556
#5  std::filesystem::__cxx11::path::path (this=0x7ec77c000f18, __p=filesystem::path <error: Cannot access memory at address 0x82cb4bc051b66be2> [root-directory])
    at /usr/src/debug/gcc/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/fs_path.h:317
#6  std::filesystem::__cxx11::path::_Cmpt::_Cmpt (this=0x7ec77c000f18) at /usr/src/debug/gcc/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/fs_path.h:859
#7  std::_Construct<std::filesystem::__cxx11::path::_Cmpt, std::filesystem::__cxx11::path::_Cmpt const&> (__p=0x7ec77c000f18)
    at /usr/src/debug/gcc/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/stl_construct.h:119
#8  std::__do_uninit_copy<std::filesystem::__cxx11::path::_Cmpt const*, std::filesystem::__cxx11::path::_Cmpt*> (__first=0x7ec77c000d78, __last=0x7ec77c000e68, __result=0x7ec77c000f18)
    at /usr/src/debug/gcc/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/stl_uninitialized.h:120
#9  std::__uninitialized_copy<false>::__uninit_copy<std::filesystem::__cxx11::path::_Cmpt const*, std::filesystem::__cxx11::path::_Cmpt*>
    (__first=<optimized out>, __last=0x7ec77c000e68, __result=0x7ec77c000f18) at /usr/src/debug/gcc/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/stl_uninitialized.h:137
#10 std::uninitialized_copy<std::filesystem::__cxx11::path::_Cmpt const*, std::filesystem::__cxx11::path::_Cmpt*> (__first=<optimized out>, __last=0x7ec77c000e68, __result=0x7ec77c000f18)
    at /usr/src/debug/gcc/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/stl_uninitialized.h:185
#11 std::__uninitialized_copy_n<std::filesystem::__cxx11::path::_Cmpt const*, int, std::filesystem::__cxx11::path::_Cmpt*> (__first=<optimized out>, __n=5, __result=0x7ec77c000f18)
    at /usr/src/debug/gcc/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/stl_uninitialized.h:900
#12 std::uninitialized_copy_n<std::filesystem::__cxx11::path::_Cmpt const*, int, std::filesystem::__cxx11::path::_Cmpt*> (__first=<optimized out>, __n=5, __result=0x7ec77c000f18)
    at /usr/src/debug/gcc/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/stl_uninitialized.h:950
#13 std::filesystem::__cxx11::path::_List::_Impl::copy (this=<optimized out>) at /usr/src/debug/gcc/gcc/libstdc++-v3/src/c++17/fs_path.cc:251
#14 0x00007ec7a31ab3bd in std::filesystem::__cxx11::path::_List::_List (this=this@entry=0x7ec78f7f5540, other=...)
    at /usr/src/debug/gcc/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/unique_ptr.h:454
#15 0x0000632c47187248 in std::filesystem::__cxx11::path::path
    (this=0x7ec78f7f5520, __p=filesystem::path "/run/user/1000/hypr/0bd541f2fd902dbfa04c3ea2ccf679395e316887_1736876316_2123961557" = {...}) at /usr/include/c++/14.2.1/bits/fs_path.h:317
#16 std::filesystem::__cxx11::operator/
    (__lhs=filesystem::path "/run/user/1000/hypr/0bd541f2fd902dbfa04c3ea2ccf679395e316887_1736876316_2123961557" = {...}, __rhs=filesystem::path "0bd541f2fd902dbfa04c3ea2ccf679395e316887_1736876316_2123961557") at /usr/include/c++/14.2.1/bits/fs_path.h:593
#17 0x0000632c471d734a in waybar::modules::hyprland::IPC::getSocketFolder[abi:cxx11](char const*)
    (instanceSig=0x7ffdc6f03de3 "0bd541f2fd902dbfa04c3ea2ccf679395e316887_1736876316_2123961557") at ../src/modules/hyprland/backend.cpp:40
#18 0x0000632c471d9fef in waybar::modules::hyprland::IPC::startIPC()::{lambda()#1}::operator()() const () at ../src/modules/hyprland/backend.cpp:70
#19 0x00007ec7a30e1c34 in std::execute_native_thread_routine (__p=0x632c84e72690) at /usr/src/debug/gcc/gcc/libstdc++-v3/src/c++11/thread.cc:104
#20 0x00007ec7a2db439d in start_thread (arg=<optimized out>) at pthread_create.c:447
#21 0x00007ec7a2e3949c in __GI___clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:78

@TAforever In the gitlab issue they asked for a stacktrace with debug symbols enabled. If you want feel free to copy this one and post it over there too. I don't have an account and don't feel like bothering with sending them an email to make one.

[Antiz96]

Hi everyone 👋

Arch Linux package maintainer for the waybar package here.

[...] At first I suspected that 92242f0 fixed the issue already, but since it also doesnt occur with a self-compiled version 0.11.0 this doesnt seem to be the case.

The plot is thickening: I have pulled the the waybar package repo (https://gitlab.archlinux.org/archlinux/packaging/packages/waybar) and built the package from the PKGBUILD, which should give me the same binary as the one installed via pacman, but the issue disappears when using the custom build. I disabled the check() inside PKGBUILD and disabled the tests flag, because I had issues linking with Catch on my system. However that shouldn't change anything.

So I guess this is an issue with the package and not inherent to waybar? Feel free to close the issue if you don't want to investigate further.

@Lauchmelder23 Thanks a lot for the investigation. Just to make things clear, the above could easily be wrong. It all depends on how you built the package & what tooling you used. To quote our bug wrangler from the related ticket opened on the Arch side: "Official Arch package are built in a clean chroot with very specific *FLAGS, when it comes to intermittent / "hard to repro" issues like this, the details matter!"

I might be wrong obviously, but that still looks like an upstream issue to me (rather than a packaging one). We do agree however that 92242f0 should most likely fix the issue. I backported that commit into the waybar v0.11.0-6 package (see https://gitlab.archlinux.org/archlinux/packaging/packages/waybar/-/commit/aed3eb1226262c95e857449c0ad92be4e5b22be3). Can you please check if you're able to reproduce the issue with that version?

Thanks in advance :)

[Lauchmelder23]

@Antiz96 The backport appears to fix the issue for me :) Several restarts and the waybar hasn't failed once. Occasionally it takes noticeably longer to load (up to 1 second after the wallpapers are loaded), which I assume was the case where it previously would have crashed.

Thank you for the swift action, hope to see 0.11.0-6 in extra soon