D-Bus arrays are serialized as follows:
1. align to a 4-byte boundary (for the length)
2. uint32: the length of the serialized body in bytes
3. padding for the alignment of the body type (not included in the length)
4. the body.
Note that 3. is a no-op unless the body type is an 8-byte aligned type
(uint64, int64, double, struct, dict_entry), since you are always on a
4-byte boundary from aligning and writing the length.
So, an empty aax (that is, an array containing zero arrays of int64)
is serialized as follows:
1. align to a 4-byte boundary
2. length of the contents of this (empty) array, in bytes (0)
3. align to a 4-byte boundary (the child array's alignment requirement)
4. there is no body.
But previously, GDBus would recurse in step three to align not just for
the type of the child array, but for the nonexistent child array's
contents. This only affects the algorithm when the grandchild type has
8-byte alignment and the reader happened to not already be on an 8-byte
boundary, in which case 4 bytes were spuriously skipped.
https://bugzilla.gnome.org/show_bug.cgi?id=673612
Signed-off-by: David Zeuthen <davidz@redhat.com>
When cross-compiling with linaro toolchain 4.6.2, I got several
linking errors about missing symbols because a couple libraries are
not linked.
This patch adds to the LDADD flags the missed libraries.
This patch applies above the glib-2-30 branch.
Signed-off-by: Víctor Manuel Jáquez Leal <vjaquez@igalia.com>
https://bugzilla.gnome.org/show_bug.cgi?id=671711
This was a regression in commits f41178c6c and d0d04c09: flush_async_data
wasn't necessarily NULL in the "don't flush" case.
Also move initialization of these variables up so that it's
unconditional, since that's easier to verify than checking
that each branch gets it right.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=664617
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
We didn't previously flush in a couple of cases where we should have
done:
* a write is running when flush is called: we should flush after it
finishes
* writes have been made since the last flush, but none are pending or
running right now: we should flush the underlying transport straight
away
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=662395
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Cosimo Alfarano <cosimo.alfarano@collabora.co.uk>
This makes it easier to schedule a flush, by putting it on the same code
path as writing and closing.
Also change message_written to expect the lock to be held, since all
that's left in that function either wants to hold the lock or doesn't
care, and it's silly to release the lock immediately before calling
message_written, which just takes it again.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=662395
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Cosimo Alfarano <cosimo.alfarano@collabora.co.uk>
If the user calls flush_sync() with no messages in the queue, but an
async write call pending, then we ought to flush after that async write
returns (although we don't currently do that). If it was an async close
or flush that was pending, there's no need to flush (again) afterwards.
So, we need to distinguish.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=662395
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Cosimo Alfarano <cosimo.alfarano@collabora.co.uk>
My previous fix for GNOME#662100 was incomplete: it seems that with some
timings, the stream can be closed with an async read in-flight. This
can make the read fail immediately with G_IO_ERROR_CLOSED instead of
becoming cancelled.
This happens reliably on an embedded device, and rarely on my laptop;
repeating the test 100 times in quick succession reliably reproduces
the bug on my laptop.
It seems as though what we really want is to ignore read errors, once
we've established that we want to close the connection anyway - this
means that after asking to close, you're immune to exit-on-close,
which seems like a good rule.
An additional subtlety is that continuing to read after we know we
want to close is still required, otherwise we'll never emit ::closed.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=662100
Bug-NB: NB#287088
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Colin Walters <walters@verbum.org>
If the GDBusObjectManagerClient doesn't get a name owner during its lifetime,
`on_control_proxy_g_signal' will never be connected to any signal, so we
shouldn't dump any warning in that case.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=662858
As part of the deserialisation process of a zero-length array in the
DBus wire format, parse_value_from_blob() recursively calls itself with
the expectation of failing (as can be seen by the assert immediately
following).
It passes &local_error to this always-failing call and then fails to
free it (indeed, to use it at all). The result is that the GError is
leaked.
Fix it by passing in NULL instead, so that the GError is never created
in the first place.
https://bugzilla.gnome.org/show_bug.cgi?id=662411
Also document which fields require such a check in order to have correct
threading semantics.
This usage doesn't matches the GInitable documentation, which suggests
use of a GError - but using an uninitialized GDBusConnection is
programming error, and not usefully recoverable. (The GInitable
documentation may have been a mistake - GNOME#662208.) Also, not all of
the places where we need it can raise a GError.
The check serves a dual purpose: it turns a non-deterministic crash into
a deterministic critical warning, and is also a memory barrier for
thread-safety. All of these functions dereference or return fields that
are meant to be protected by FLAG_INITIALIZED, so they could crash or
return an undefined value to their caller without this, if called from a
thread that isn't the one that called initable_init() (although I can't
think of any way to do that without encountering a memory barrier,
undefined behaviour, or a race condition that leads to undefined
behaviour if the non-initializing thread wins the race).
One exception is that initable_init() itself makes a synchronous call.
We deal with that by passing new internal flags up the call stack, to
reassure g_dbus_connection_send_message_unlocked() that it can go ahead.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=661689
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=661992
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: David Zeuthen <davidz@redhat.com>
The comment implied that even failed initialization would set
is_initialized = TRUE, but this wasn't the case - failed initialization
would only set initialization_error, and it was necessary to check both.
It turns out the documented semantics are nicer than the implemented
semantics, since this lets us use atomic operations, which are also
memory barriers, to avoid needing separate memory barriers or locks
for initialization_error (and other members that are read-only after
construction).
I expect to need more than one atomically-accessed flag to fix thread
safety, so instead of a minimal implementation I've turned is_initialized
into a flags word.
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=661689
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=661992
Reviewed-by: David Zeuthen <davidz@redhat.com>
We didn't previously test anything except the implicit default of TRUE.
Now we test implicit TRUE, explicit TRUE, explicit FALSE, and
disconnecting at the local end (which regressed while fixing Bug #651268).
Also avoid some questionable use of a main context, which fell foul of
Bug #658999 and caused this test to be disabled in master.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=662100
Bug-NB: NB#287088
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: David Zeuthen <davidz@redhat.com>
(cherry picked from commit be89f052c2)
This was a regression caused by my previous work on GDBusWorker thread-safety
(Bug #651268). The symptom is that if you disconnect a GDBusConnection
locally, the default implementation of GDBusConnection::closed
terminates your process, even though it shouldn't do that for
locally-closed connections; this is because GDBusWorker didn't think a
cancelled read was a local close.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=662100
Bug-NB: NB#287088
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: David Zeuthen <davidz@redhat.com>
(cherry picked from commit 5e0492da50)
GDBusConnection sets the closed flag in the worker thread, then adds an
idle callback (which refs the Connection) to signal this in the main
thread. The tests session_bus_down doesn't spin the mainloop, so the
"closed" signal will always fire if iterating the mainloop later (and
drops the ref when doing so). But _is_closed can return TRUE even before
signalling this, in which case the "closed" signal isn't fired and the
ref isn't dropped, causing the test to fail.
Instead simply always wait for the closed signal, which is a good thing
to check anyway and ensures the ref is closed.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=661896
Reviewed-by: Matthias Clasen <mclasen@redhat.com>
GVDB deals with empty lists by returning NULL for the list instead of a
zero-length (non-NULL) strv. We can work around that in GSettingsSchema
by checking for the NULL case and treating it like a zero-length list.
https://bugzilla.gnome.org/show_bug.cgi?id=660147
If the connection to the bus is lost while a method call is ongoing,
the method call does not get cancelled. Instead it just sits around
until it times out.
This is visible here on XO laptops when stopping the display manager
during shutdown. imsettings starts sending a sync message to give up
its bus name (via g_bus_unown_name()), then systemd terminates the
session bus at approximately the same time. imsettings then hangs for
about 20 seconds before timing out the message.
http://lists.freedesktop.org/archives/dbus/2011-September/014717.html
imsettings behaviour could be improved as described in that thread,
but I think this is a glib bug. I've also come up with the attached
patch which fixes it.
Credits for the bug-fix goes to Daniel Drake <dsd@laptop.org>. The test
case was written by David Zeuthen <zeuthen@gmail.com>.
https://bugzilla.gnome.org/show_bug.cgi?id=660637
Signed-off-by: David Zeuthen <davidz@redhat.com>
Since it is valid for a D-Bus interface / service to add new methods,
signals or properties we must NEVER warn about unknown properties or
drop unknown signals or disallow unknown method invocations when we
have an expected interface.
So this means that the expected_interface machinery is only useful for
checking that the service didn't break ABI.
Also update the docs so it is clear exactly what it means to have an
expected interface.
https://bugzilla.gnome.org/show_bug.cgi?id=660886
Signed-off-by: David Zeuthen <davidz@redhat.com>
g_file_make_directory_with_parents() will fail for already
existing directories, unlike g_mkdir_with_parents(), so mention
this clearly in the docs.
https://bugzilla.gnome.org/show_bug.cgi?id=660791
Previously, we took the default application for a particular mimetype
from the system and copied it into the user's configuration as the
default there.
Instead of doing that we leave the user's default unset, and at time of
use, if the user has no explicitly-set default value, we use the system
default.
This avoids complicated situations where inappropriate applications were
being set as the default in the user's configuration.
https://bugzilla.gnome.org/show_bug.cgi?id=658188
We ignore entries with mountpoint of "swap" and "ignore". Add "none" to
that list, since Debian uses it.
Probably we should move to using our already-existing internal list of
things to ignore, but this patch is more minimally intrusive for now.
https://bugzilla.gnome.org/show_bug.cgi?id=654563
Commit afa82ae805 introduced a compilation
regression on BSD systems that use the sysctl(3) interface; we need to
declare the buffer len in _g_get_unix_mount_points()
BZ #659528
