If --uninstall is given then don't give an error if the schema directory
is empty. Instead, erase the gschemas.compiled file, if it exists.
This is the right thing to do in the 'make uninstall' rule, where the
schema directory could very well be left empty as a result.
Modify gsettings.m4 to use this option.
The test was assuming that g_timeout_add() waited for at least the amount of
time given to it before running the function. This is not the case -- the
function can be run as much as 1ms early. Make the lower time bound asserted
in the test more permissive to account for this.
- hold a lock while accessing the tree of delayed values
- use weak reference counts with the owner object to avoid doing
g_object_notify on a dead object
- dispatch the "has-unapplied" notify to the proper main context
This commit fixes up a few race conditions in the GSettingsBackend, mostly with
respect to change notifications occuring at the same time as the last reference
count on a GSettings is dropped. With GDBus feeding us our incoming signals in
a separate thread, this is something that could easily happen.
There is currently no way (near as I can tell) to ensure that a message
has been sent when using GDBus. If we exit() before we are sure, then
it is very possible that the message isn't sent at all. This behaviour
was observed when using the GSettings commandline tool with dconf.
A quick and dirty workaround for now.
Don't define __USE_GNU, thats a glibc-internal macro, and
don't use SOL_SOCKET when not including sys/socket.h.
Maybe this file should be called glinuxcredentialsmessage.c...
Bug #618730
Rename the --schema-files option to --schema-file, since it only
accepts one file at a time. Change the GSETTINGS_CHECK_RULE to
use it that way, too. And also make it work better with !srcdir
builds.
Bugs #616731 and #616864
Without this fix, we segfault if the exported object returned an error
on all get_property() calls (in reality, this never happens).
Signed-off-by: David Zeuthen <davidz@redhat.com>
Fix an unintentional double free introduced in commit
4ad4c306c3.
This bug manifested itself when trying to complete this
$ gdbus introspect --system --dest <tab>
From valgrind running gdbus-peer test:
==20513== 32 bytes in 1 blocks are definitely lost in loss record 1 of 15
==20513== at 0x4024E4C: realloc (vg_replace_malloc.c:429)
==20513== by 0x4079BB1: g_realloc (gmem.c:174)
==20513== by 0x4099472: g_string_maybe_expand (gstring.c:396)
==20513== by 0x409A42A: g_string_insert_c (gstring.c:1050)
==20513== by 0x42169AC: g_string_append_c_inline (gstring.h:153)
==20513== by 0x421682C: _my_g_input_stream_read_line_safe (gdbusauth.c:336)
==20513== by 0x421843E: _g_dbus_auth_run_server (gdbusauth.c:1265)
==20513== by 0x4222B94: initable_init (gdbusconnection.c:1783)
==20513== by 0x41CF8D5: g_initable_init (ginitable.c:106)
==20513== by 0x41CFA8D: g_initable_new_valist (ginitable.c:219)
==20513== by 0x41CF920: g_initable_new (ginitable.c:139)
==20513== by 0x4223479: g_dbus_connection_new_sync (gdbusconnection.c:2046)
Bug #618650.
==6279== 21,615 (4,708 direct, 16,907 indirect) bytes in 169 blocks are
definitely lost in loss record 12 of 13
==6279== at 0x4024D2E: malloc (vg_replace_malloc.c:207)
==6279== by 0x4079A90: g_malloc (gmem.c:135)
==6279== by 0x4079DC8: g_malloc_n (gmem.c:252)
==6279== by 0x4097E66: g_strsplit (gstrfuncs.c:2434)
==6279== by 0x42169A2: g_dbus_address_get_stream_sync
(gdbusaddress.c:875)
Bug #618622.
Free the bus address after creating the singleton.
==26308== 39,736 (10,517 direct, 29,219 indirect) bytes in 388 blocks
are definitely lost in loss record 14 of 15
==26308== at 0x4024D2E: malloc (vg_replace_malloc.c:207)
==26308== by 0x4079A90: g_malloc (gmem.c:135)
==26308== by 0x4079DC8: g_malloc_n (gmem.c:252)
==26308== by 0x4095607: g_strdup (gstrfuncs.c:102)
==26308== by 0x4216B9A: g_dbus_address_get_for_bus_sync
(gdbusaddress.c:961)
==26308== by 0x422A7AE: get_uninitialized_connection
(gdbusconnection.c:5241)
Bug #618622.
