When g_settings_apply() is called on a delayed settings backend and
there is a D-Bus error when communicating with dconf-service, recent
versions of the dconf GSettingsBackend call a function in GLib that
improperly delivered the signal directly instead of using
g_main_context_invoke().
This patch fixes this function to route in the same way as the others so
that the signal is dispatched in the proper GMainContext.
Previously, we were returning an empty buffer for all filenames
where fstat() gives a size of 0. But this is only appropriate
for regular files.
Also improve the documentation around this issue. Based on a
patch by Ryan Lortie.
mmap() fails on zero-sized files, so we previously had a special case to
avoid calling it in that case. Unfortunately, this had the side effect
of causing us to fail to notice that we were attempting to mmap() a
device node.
Modify the special-casing to only apply in the case that we're dealing
with a normal file.
https://bugzilla.gnome.org/show_bug.cgi?id=659212
Otherwise, we could use-after-free the GDBusWorker, if its last-unref
is immediately after _g_dbus_worker_new returns (before the worker thread
does its initial read).
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=651268
Bug-NB: NB#271520
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Signed-off-by: David Zeuthen <davidz@redhat.com>
This member is written in _g_dbus_worker_stop from arbitrary threads, and
read by the worker thread, so it should be accessed atomically.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=651268
Bug-NB: NB#271520
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Signed-off-by: David Zeuthen <davidz@redhat.com>
We can't safely close the output part of the I/O stream until any
pending write or flush has been completed. In the worst case, this could
lead to an assertion failure in the worker (when the close wins the
race) or not closing the stream at all (when the write wins the race).
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=651268
Bug-NB: NB#271520
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Signed-off-by: David Zeuthen <davidz@redhat.com>
num_writes_pending was a counter, but it only took values 0 or 1, so make
it a boolean: it would never make sense to be trying to write out two
messages at the same time (they'd get interleaved).
Similarly, we can never be writing and flushing at the same time (that'd
mean we were flushing halfway through a message, which would be pointless)
so combine it with flush_pending too, calling the result output_pending.
Also assert that it takes the expected value whenever we change it,
and document the locking discipline used for it, including a subtle
case in write_message_in_idle_cb where it's not obvious at first glance
why we don't need the lock.
(Having the combined boolean at the top of the block of write-related
struct members improves struct packing on 64-bit platforms, by packing
read_num_ancillary_messages and output_pending into one word.)
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=651268
Bug-NB: NB#271520
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Signed-off-by: David Zeuthen <davidz@redhat.com>
The 'key' variable is no longer valid outside the cycle, owned and
probably already freed by GVariant. This causes apps to segfault
when proxy is constructed and a property on remote d-bus service
changes (actually is invalidated). Looks like a typo anyway.
https://bugzilla.gnome.org/show_bug.cgi?id=659070
* Do not ignore the system default
* Do not exclude the last used being set from the default list
This fixes the default applications dialog in control-center.
https://bugzilla.gnome.org/show_bug.cgi?id=658188
Only objects and interfaces should go in here. If enums are in here
then gtk-doc responds by outputting two anchors for the same name (which
results in many warnings being printed).
