Unkown segmentation fault (removing tray icon?) about gbar HOT 5 OPEN

I can get you the dump over the weekend (its on my work laptop).

from gbar.

Very strange...
I too notice random crashes, but cannot pin point them to anything.
Can you open the crash dump with gdb and run bt, so I know what to look for?

from gbar.

Okay, the wall of SNI: Cannot remove unregistered bus name xxx should now be fixed. I don't know whether this was the cause of the crash, though, so the crash dump is still appreciated.

from gbar.

I may or may not have the same error. One reliable way for me to break it is by loading syncthingtray and starting gBar as a systemd service. I can also break it when starting gBar from the shell and interacting with any icon. I then get a similar behavior as @kragebein . When I start from systemd however it segfaults "cleanly" and I get a better log for whats happening.

gbar.log

I think the problem is similar to a problem that happens with the tray icon support in developement for eww. It has been adressed in this PR.
Apparently we need to disable caching for IconName as per https://dbus2.github.io/zbus/faq.html#why-arent-property-values-updating-for-my-service-that-doesnt-notify-changes, as well as for the IconPixmap property. I don't know how this translates to C++ though.

from gbar.

The logs point towards a crash in gtk_widget_destroy (although the LOG I do before calling gtk_widget_destroy is not there, which is a bit weird). So this seems to be like there is some sort of memory corruption or double-free going on (Even though gtk_widget_destroy should check against that). Unfortunately I still can't reproduce this even with systemd + syncthingtray and valgrind also doesn't show something suspicous. So I'm out of ideas as to what can fix this.

I don't think this is similar to the linked PR, since the caching is something related to the library used, which I don't use (I use gio)

from gbar.