Waybar icon indicating copy to clipboard operation
Waybar copied to clipboard

Crash

Open hanckmann opened this issue 2 years ago • 9 comments

Waybar crashes frequently with the following error:

malloc(): unaligned tcache chunk detected
[1]    39455 IOT instruction (core dumped)  waybar

If you need more information, please let me know how to provide it and I will try to do so.

Also note the following info:

λ ~/ waybar --version
Waybar v0.9.10

λ ~/ screenfetch
                   -`                 
                  .o+`                 patrick@plato
                 `ooo/                 OS: Arch Linux 
                `+oooo:                Kernel: x86_64 Linux 5.16.12-zen1-1-zen
               `+oooooo:               Uptime: 7h 27m
               -+oooooo+:              Packages: 1525
             `/:-:++oooo+:             Shell: zsh 5.8.1
            `/++++/+++++++:            Resolution: 1745x981
           `/++++++++++++++:           WM: sway
          `/+++ooooooooooooo/`         GTK Theme: WhiteSur-light [GTK2/3]
         ./ooosssso++osssssso+`        Icon Theme: WhiteSur
        .oossssso-````/ossssss+`       Font: Noto Sans,  10
       -osssssso.      :ssssssso.      Disk: 3.9T / 4.1T (94%)
      :osssssss/        osssso+++.     CPU: AMD Ryzen 7 PRO 4750U with Radeon Graphics @ 16x 1.7GHz
     /ossssssss/        +ssssooo/-     GPU: AMD/ATI
   `/ossssso+/:-        -:/+osssso+-   RAM: 3678MiB / 31383MiB
  `+sso+:-`                 `.-/+oso: 
 `++:.                           `-/+/
 .`                                 `/

hanckmann avatar Mar 07 '22 20:03 hanckmann

I am willing to help, but I am not sure how to start. Can you give some quick pointers?

Like; should I build in debug mode... and how... are there other important pointers?

hanckmann avatar Mar 08 '22 10:03 hanckmann

I also see frequent (one per couple of hours) crashes. A coredump shows that resizing a string (inside Ipc::recv) caused an abort. In another coredump the abort also occured in malloc, but with a completely different backtrace. Maybe there is some heap corruption taking place? I try to debug this further by tracing the allocations.

#0  0x00007f0869e7234c in __pthread_kill_implementation () at /usr/lib/libc.so.6
#1  0x00007f0869e254b8 in raise () at /usr/lib/libc.so.6
#2  0x00007f0869e0f534 in abort () at /usr/lib/libc.so.6
#3  0x00007f0869e66397 in __libc_message () at /usr/lib/libc.so.6
#4  0x00007f0869e7c33c in  () at /usr/lib/libc.so.6
#5  0x00007f0869e7cfa0 in ptmalloc_init.part () at /usr/lib/libc.so.6
#6  0x00007f0869e7f103 in _int_malloc () at /usr/lib/libc.so.6
#7  0x00007f0869e80629 in malloc () at /usr/lib/libc.so.6
#8  0x00007f086a19641d in operator new(unsigned long) (sz=13635) at /usr/src/debug/gcc/libstdc++-v3/libsupc++/new_op.cc:50
#9  0x000055a0e3ab033c in std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_mutate(unsigned long, unsigned long, char const*, unsigned long)
    (this=this@entry=0x7f085dffa950, __pos=__pos@entry=0, __len1=__len1@entry=0, __s=__s@entry=0x0, __len2=__len2@entry=13634) at /usr/include/c++/11.2.0/bits/basic_string.tcc:307
#10 0x000055a0e3afdce2 in std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_replace_aux(unsigned long, unsigned long, unsigned long, char) (__c=0 '\000', __n2=13634, __n1=0, __pos1=0, this=0x7f085dffa950)
    at /usr/include/c++/11.2.0/bits/basic_string.tcc:437
#11 std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::append(unsigned long, char) (__c=0 '\000', __n=13634, this=0x7f085dffa950) at /usr/include/c++/11.2.0/bits/basic_string.h:1272
#12 std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::resize(unsigned long, char) (this=this@entry=0x7f085dffa950, __n=13634, __c=__c@entry=0 '\000') at /usr/include/c++/11.2.0/bits/basic_string.tcc:377
#13 0x000055a0e3afcecf in std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::resize(unsigned long) (__n=<optimized out>, this=0x7f085dffa950) at /usr/include/c++/11.2.0/bits/basic_string.h:957
#14 waybar::modules::sway::Ipc::recv(int) (this=0x7f085dffa940, fd=18) at ../src/modules/sway/ipc/client.cpp:100

tomprogrammer avatar Mar 08 '22 14:03 tomprogrammer

How did you generate that core dump? I would like to know the exact error for my issue (as well).

hanckmann avatar Mar 08 '22 19:03 hanckmann

I also run Arch Linux which uses systemd. You can use coredumpctl and coredumpctl debug $PID to list coredumps and start gdb on the coredump. The command bt shows the backtrace in gdb. I think the systemd-coredump.socket is enabled per default, so you should have some coredumps recorded too.

tomprogrammer avatar Mar 08 '22 21:03 tomprogrammer

This is my coredump:

Core was generated by `./waybar'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x00007f417f82cd24 in ?? () from /usr/lib/libgtk-3.so.0
[Current thread is 1 (Thread 0x7f417b151240 (LWP 28399))]
(gdb) bt
#0  0x00007f417f82cd24 in  () at /usr/lib/libgtk-3.so.0
#1  0x00007f417f240ef2 in  () at /usr/lib/libglib-2.0.so.0
#2  0x00007f417f245074 in g_hash_table_unref () at /usr/lib/libglib-2.0.so.0
#3  0x00007f417f82fa69 in  () at /usr/lib/libgtk-3.so.0
#4  0x00007f417f827b76 in  () at /usr/lib/libgtk-3.so.0
#5  0x00007f417f81bd98 in  () at /usr/lib/libgtk-3.so.0
#6  0x00007f417f7c2aca in  () at /usr/lib/libgtk-3.so.0
#7  0x00007f417f992fae in  () at /usr/lib/libgtk-3.so.0
#8  0x00007f417f993c6d in gtk_widget_get_preferred_height_and_baseline_for_width () at /usr/lib/libgtk-3.so.0
#9  0x00007f417f7ca3d3 in  () at /usr/lib/libgtk-3.so.0
#10 0x00007f417f814fe7 in  () at /usr/lib/libgtk-3.so.0
#11 0x00007f417f81bf5d in  () at /usr/lib/libgtk-3.so.0
#12 0x00007f417f7c2aca in  () at /usr/lib/libgtk-3.so.0
#13 0x00007f417f992fae in  () at /usr/lib/libgtk-3.so.0
#14 0x00007f417f993a09 in gtk_widget_get_preferred_height () at /usr/lib/libgtk-3.so.0
#15 0x00007f417fa619cb in  () at /usr/lib/libgtk-3.so.0
#16 0x00007f417f992fae in  () at /usr/lib/libgtk-3.so.0
#17 0x00007f417f993c6d in gtk_widget_get_preferred_height_and_baseline_for_width () at /usr/lib/libgtk-3.so.0
#18 0x00007f417fb0a094 in  () at /usr/lib/libgtk-3.so.0
#19 0x00007f417fa5e852 in  () at /usr/lib/libgtk-3.so.0
#20 0x00007f417fa631ac in  () at /usr/lib/libgtk-3.so.0
#21 0x00007f417f36fc96 in g_signal_emit_valist () at /usr/lib/libgobject-2.0.so.0
#22 0x00007f417f36fe04 in g_signal_emit () at /usr/lib/libgobject-2.0.so.0
#23 0x00007f417f810f79 in  () at /usr/lib/libgtk-3.so.0
#24 0x00007f417f36fc96 in g_signal_emit_valist () at /usr/lib/libgobject-2.0.so.0
#25 0x00007f417f36fe04 in g_signal_emit () at /usr/lib/libgobject-2.0.so.0
#26 0x00007f417f655850 in  () at /usr/lib/libgdk-3.so.0
#27 0x00007f417f6426b0 in  () at /usr/lib/libgdk-3.so.0
#28 0x00007f417f2576d8 in  () at /usr/lib/libglib-2.0.so.0
#29 0x00007f417f256ee3 in g_main_context_dispatch () at /usr/lib/libglib-2.0.so.0
#30 0x00007f417f2ad0f9 in  () at /usr/lib/libglib-2.0.so.0
#31 0x00007f417f254455 in g_main_context_iteration () at /usr/lib/libglib-2.0.so.0
#32 0x00007f417f5266ee in g_application_run () at /usr/lib/libgio-2.0.so.0
#33 0x000055eef828cf55 in waybar::Client::main(int, char**) ()
#34 0x000055eef828be7d in main ()

hanckmann avatar Mar 09 '22 08:03 hanckmann

This is a little over my head (I have zero experience with gtk programming). The main change I see is the new window icon support. So, I will first move forward and disable that and see if waybar becomes (more) stable:

    "sway/window": {
        "icon": false,
    },

hanckmann avatar Mar 09 '22 08:03 hanckmann

I have been having the same problems on the latest version of waybar (Waybar v0.9.10). I disabled window icon support as suggested and have had no issues. (Working 5+ hours without a crash)

msahlen avatar Mar 10 '22 10:03 msahlen

Same problem but different "solution". I'm on Waybar v0.9.9 I did use the default config as a starting point and everything worked perfectly and looked good except for the backlight icons. OTF icons are installed and displayed correctly for anything else. screenshot_2022-04-26_12-20-09_262230377

Removing the icons from the backlight module "fixed" it for me.

Core dumb:

Core was generated by `waybar -b bar-0'.
Program terminated with signal SIGTRAP, Trace/breakpoint trap.
#0  0x00007fc094338ccf in g_log_structured_array () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
[Current thread is 1 (Thread 0x7fc090911ac0 (LWP 28121))]
(gdb) bt
#0  0x00007fc094338ccf in g_log_structured_array () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#1  0x00007fc094338f99 in g_log_default_handler () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x00007fc09433a3fa in g_logv () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x00007fc09433a6e3 in g_log () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#4  0x00007fc0944e39e2 in ?? () from /lib/x86_64-linux-gnu/libglibmm-2.4.so.1
#5  0x00007fc0944e3bd4 in ?? () from /lib/x86_64-linux-gnu/libglibmm-2.4.so.1
#6  0x00007fc0944feb40 in Glib::IOSource::dispatch(sigc::slot_base*) () from /lib/x86_64-linux-gnu/libglibmm-2.4.so.1
#7  0x00007fc0944f7ba7 in Glib::Source::dispatch_vfunc(_GSource*, int (*)(void*), void*) () from /lib/x86_64-linux-gnu/libglibmm-2.4.so.1
#8  0x00007fc094331c24 in g_main_context_dispatch () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#9  0x00007fc0943866f8 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#10 0x00007fc09432f3c3 in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#11 0x00007fc09460cc85 in g_application_run () from /lib/x86_64-linux-gnu/libgio-2.0.so.0
#12 0x000056028336f413 in ?? ()
#13 0x000056028336dfdd in main ()

JayGray avatar Apr 26 '22 10:04 JayGray

Well, never mind. Just build from scratch and it is not reproducible anymore.

❯ waybar --version    
Waybar v0.9.12-88-gcaee2e6 (branch 'master')

JayGray avatar Apr 26 '22 10:04 JayGray