xfwm4-settings handles non-existing xconfd badly

Submitted by rindeal

Assigned to Olivier Fourdan @olivier

Link to original bug (#16440)

Description

When trying to run xfwm4-settings 4.12 without xconfd installed this segfault always happen.

Here is a backtrace:

#0  0x000055555555cc8c in xfwm_settings_button_layout_property_changed (channel=`<optimized out>`, property=0x55555555dbcd "/general/button_layout", settings=`<optimized out>`, 
    value=0x7fffffffd880) at xfwm4-settings.c:1397
#1  xfwm_settings_constructed (object=`<optimized out>`) at xfwm4-settings.c:501
#2  0x00007ffff6a653d0 in g_object_new_internal (class=class@entry=0x5555558f30f0, params=params@entry=0x7fffffffdaa0, n_params=n_params@entry=1) at gobject.c:1837
#3  0x00007ffff6a6713e in g_object_new_valist (object_type=`<optimized out>`, first_property_name=`<optimized out>`, var_args=var_args@entry=0x7fffffffdbf0) at gobject.c:2120
#4  0x00007ffff6a674b9 in g_object_new (object_type=`<optimized out>`, first_property_name=`<optimized out>`) at gobject.c:1640
#5  0x0000555555559315 in main (argc=`<optimized out>`, argv=`<optimized out>`) at xfwm4-settings.c:931

Upon quick inspection of the source code I see that the immediate problem is not checking the return status of xfconf_channel_get_property(), which sadly seems to be a coding convention across the codebase there, but then happily acting upon its result value. The same then applies inside xfwm_settings_button_layout_property_changed():

for (str_value = g_value_get_string (value); *str_value != '\0'; ++str_value)

again, not checking the return value of g_value_get_string(), but happily de-referencing it, which has been causing the segfault. This was fixed 10 months ago in https://git.xfce.org/xfce/xfwm4/commit/?id=5ece9b89905cfa65023f00b8e185fbf438c076f8, however, so it no longer crashes, instead the critical Glib assertion is still triggered and all configuration changes are silently ignored (tested on 4.14).

xfconf_channel_get_property() fails, because it cannot communicate with xconfd via dbus. This case should be handled gracefully instead of failing miserably or being silently ignored.