I'm getting lots of these criticals. The backtrace is: Thread 1 "xfdesktop" received signal SIGTRAP, Trace/breakpoint trap. 0x00007ffff399ccd2 in ?? () from /usr/lib/libglib-2.0.so.0 (gdb) bt #0 0x00007ffff399ccd2 in () at /usr/lib/libglib-2.0.so.0 #1 0x00007ffff399d50d in g_logv () at /usr/lib/libglib-2.0.so.0 #2 0x00007ffff399d680 in g_log () at /usr/lib/libglib-2.0.so.0 #3 0x00007ffff39a822b in g_base64_encode_step () at /usr/lib/libglib-2.0.so.0 #4 0x00007ffff39ade53 in g_base64_encode () at /usr/lib/libglib-2.0.so.0 #5 0x00007ffff54836c4 in () at /usr/lib/libgtk-3.so.0 #6 0x00007ffff54845e1 in () at /usr/lib/libgtk-3.so.0 #7 0x00007ffff549078e in gtk_css_provider_to_string () at /usr/lib/libgtk-3.so.0 #8 0x000055555557f11c in xfdesktop_application_theme_changed (settings=settings@entry=0x555555804160, app=app@entry=0x5555557d80c0) at xfdesktop-application.c:653 #9 0x000055555557f2b8 in xfdesktop_application_start (app=0x5555557d80c0) at xfdesktop-application.c:695 #10 0x000055555557f6c6 in cb_wait_for_window_manager_destroyed (data=0x5555558d1f30) at xfdesktop-application.c:587 #11 0x00007ffff398ce68 in () at /usr/lib/libglib-2.0.so.0 #12 0x00007ffff3991e96 in () at /usr/lib/libglib-2.0.so.0 #13 0x00007ffff3992150 in g_main_context_dispatch () at /usr/lib/libglib-2.0.so.0 #14 0x00007ffff3993f69 in () at /usr/lib/libglib-2.0.so.0 #15 0x00007ffff3993fae in g_main_context_iteration () at /usr/lib/libglib-2.0.so.0 #16 0x00007ffff3ee31ce in g_application_run () at /usr/lib/libgio-2.0.so.0 #17 0x000055555556f288 in main (argc=1, argv=0x7fffffffe038) at main.c:58 The interesting fact is that bug seems to happen only when using Greybird (git-ff3f88e here).
Hmm also affecting xfwm4: (xfwm4:527): GLib-CRITICAL **: g_base64_encode_step: assertion 'in != NULL' failed Lots of them (uptime -> 1:43): cat ~/.local/share/sddm/xorg-session.log | grep g_base64 | wc -l 4428 Perhaps a theme issue?
What I have learned when trying other themes: Themes shipped with Xfce, Adwaita, Vertex, Vimix and Arc: no error message Numix: error messages, but fewer than Greybird
xfwm4 backtrace: (xfwm4:11399): GLib-CRITICAL **: g_base64_encode_step: assertion 'in != NULL' failed Thread 1 "xfwm4" received signal SIGTRAP, Trace/breakpoint trap. 0x00007ffff3d9e982 in ?? () from /usr/lib/libglib-2.0.so.0 #0 0x00007ffff3d9e982 in () at /usr/lib/libglib-2.0.so.0 #1 0x00007ffff3d9fced in g_logv () at /usr/lib/libglib-2.0.so.0 #2 0x00007ffff3d9fe50 in g_log () at /usr/lib/libglib-2.0.so.0 #3 0x00007ffff3d6d893 in g_base64_encode_step () at /usr/lib/libglib-2.0.so.0 #4 0x00007ffff3d6dc13 in g_base64_encode () at /usr/lib/libglib-2.0.so.0 #5 0x00007ffff5ed1a64 in () at /usr/lib/libgtk-3.so.0 #6 0x00007ffff5ed2b61 in () at /usr/lib/libgtk-3.so.0 #7 0x00007ffff5eded4e in gtk_css_provider_to_string () at /usr/lib/libgtk-3.so.0 #8 0x000055555559608e in apply_default_theme (tabwin_widget=0x555555f68270) at tabwin.c:167 #9 0x000055555559608e in tabwinCreateWidget (monitor_num=<optimized out>, screen_info=0x555555a28600, tabwin=0x555555f4a610) at tabwin.c:757 Here is the function that calls gtk_css_provider_to_string (provider): https://git.xfce.org/xfce/xfwm4/tree/src/tabwin.c#n152 The provider reference seems valid (not NULL). In both cases, I wonder if there's an easier way check if a style is present or not without getting a string representation of the provider just to look up a substring.
Here's a full backtrace of xfdesktop, gtk3 w/ debug symbols: (xfdesktop:9502): GLib-CRITICAL **: g_base64_encode_step: assertion 'in != NULL' failed Thread 1 "xfdesktop" received signal SIGTRAP, Trace/breakpoint trap. 0x00007ffff329e982 in ?? () from /usr/lib/libglib-2.0.so.0 #0 0x00007ffff329e982 in () at /usr/lib/libglib-2.0.so.0 #1 0x00007ffff329fced in g_logv () at /usr/lib/libglib-2.0.so.0 #2 0x00007ffff329fe50 in g_log () at /usr/lib/libglib-2.0.so.0 #3 0x00007ffff326d893 in g_base64_encode_step () at /usr/lib/libglib-2.0.so.0 #4 0x00007ffff326dc13 in g_base64_encode () at /usr/lib/libglib-2.0.so.0 #5 0x00007ffff4dc5fb4 in gtk_css_image_surface_print (image=<optimized out>, string=0x555555958d00) at gtkcssimagesurface.c:112 #6 0x00007ffff4dc72b8 in gtk_css_image_scaled_print (image=<optimized out>, string=0x555555958d00) at gtkcssimagescaled.c:73 #7 0x00007ffff4dd38ae in gtk_css_ruleset_print (str=0x555555958d00, ruleset=0x555555b531c0) at gtkcssprovider.c:2277 #8 0x00007ffff4dd38ae in gtk_css_provider_to_string (provider=<optimized out>) at gtkcssprovider.c:2398 #9 0x000055555557f1ac in xfdesktop_application_theme_changed (settings=settings@entry=0x555555802160, app=app@entry=0x5555557d80c0) at xfdesktop-application.c:653 #10 0x000055555557f348 in xfdesktop_application_start (app=0x5555557d80c0) at xfdesktop-application.c:695 #11 0x000055555557f756 in cb_wait_for_window_manager_destroyed (data=0x555555913590) at xfdesktop-application.c:587 Here are the related functions: https://github.com/GNOME/gtk/blob/gtk-3-22/gtk/gtkcssprovider.c#L2398 https://github.com/GNOME/gtk/blob/gtk-3-22/gtk/gtkcssprovider.c#L2277 https://github.com/GNOME/gtk/blob/gtk-3-22/gtk/gtkcssimagescaled.c#L73 https://github.com/GNOME/gtk/blob/gtk-3-22/gtk/gtkcssimagesurface.c#L112 It's now clear that gtk_css_provider_to_string fails while serializing images in base64. Putting a small g_print just before _gtk_css_value_print gets called, I found it chokes on a -gtk-icon-source property. If I remove all occurrences of -gtk-icon-source: -gtk-scaled from /usr/share/themes/Greybird/gtk-3.0/gtk-contained.css I get no more critical messages! However, I'm convinced that serializing the whole thing just to look for a style is a terrible approach.
Wait, so Greybird triggers all these warnings because it has specific styles for Xfwm4 and Xfdesktop? Yuck. I agree that themes should never be able to cause such errors. In the meantime I'll have to check what Adwaita does differently, because all the occurrences of "-gtk-icon-source: -gtk-scaled" are borrowed from it.
I noticed that Nemo also emit those critical messages because it uses a similar approach to add fallback styles: https://github.com/linuxmint/nemo/blob/e7016c87b29b9e74f04a55f08ef3610c01e59da0/src/nemo-application.c#L177 So, it seems that's the best gtk3 can provide. @Simon, I suspect the problem are the png files, maybe they have to be generated in some way to be correctly serialized.
Xfce 4.13 on Linux Manjaro: despite the fact that I'm using a theme shipped with Xfce (Adwaita Dark), from time to time the .xsession-errors log file is spammed with the error in the subject: it occurs massively in the same time for about 200 times. Eg: (xfdesktop:16774): GLib-CRITICAL **: 20:58:07.443: g_base64_encode_step: assertion 'in != NULL' failed (xfdesktop:16774): GLib-CRITICAL **: 20:58:07.443: g_base64_encode_step: assertion 'in != NULL' failed (xfdesktop:16774): GLib-CRITICAL **: 20:58:07.443: g_base64_encode_step: assertion 'in != NULL' failed (xfdesktop:16774): GLib-CRITICAL **: 20:58:07.443: g_base64_encode_step: assertion 'in != NULL' failed (xfdesktop:16774): GLib-CRITICAL **: 20:58:07.445: g_base64_encode_step: assertion 'in != NULL' failed (xfdesktop:16774): GLib-CRITICAL **: 20:58:07.445: g_base64_encode_step: assertion 'in != NULL' failed (obviously I cut the log to avoid to insert for 200 times the same message - at the same time, in this case @ 20:58:07)
Interesting, now I'm getting these error messages even with Adwaita and Arc. I filled an upstream bug: https://gitlab.gnome.org/GNOME/glib/issues/1698
So "luckily" I never poked too deeply into Greybird, I always expected this could happen. At least now it can be looked at from the correct angle (fixing stuff in Gtk+/glib). Thanks for pushing this upstream!
I'm using glib 2.60, no error messages anymore. However, I would like to keep this bug open so we don't forget about this hack. As I see, our options are: 2 1 - Let the hack be 2 - Prove that fallback styles provided applications don't work (I tried to put together a reproducer, no luck yet: https://gist.github.com/andreldm/00d6fca231789423c0576532262cb77c). 3 - Use Nemo's approach: "are we using Greybird? nothing to do, otherwise enable the hack".
So, what can we decide for this bug ? It is categorised as "blocker" for 4.14 :)
(In reply to Skunnyk from comment #11) > So, what can we decide for this bug ? It is categorised as "blocker" for > 4.14 :) For the moment I'm not interested in the issue style fallback reproducer, we may try to get rid of the hack after 4.14.
I agree, we can leave it open but also forget about it a little bit if the warnings are silenced. However, the approach is not nice, it wastes a lot of cpu cycles...
I'm closing this bug in favor following ones: Bug #15228 (Xfdesktop) Bug #15227 (Xfwm4)