This is causing very serious problems when doing out-of-tree builds from
tarballs on architectures that are different from the architecture that
the tarball was created on.
This commit breaks the build in those cases, but I'll fix that in the
next commits.
https://bugzilla.gnome.org/show_bug.cgi?id=626107
This prints all GDBusMethodInvocation API usage and is normally used
with the `incoming' option. Example:
# G_DBUS_DEBUG=incoming,return ./polkitd --replace
Entering main event loop
Connected to the system bus
Registering null backend at priority -10
[...]
Acquired the name org.freedesktop.PolicyKit1
[...]
========================================================================
GDBus-debug:Incoming:
<<<< METHOD INVOCATION org.freedesktop.PolicyKit1.Authority.RegisterAuthenticationAgent()
on object /org/freedesktop/PolicyKit1/Authority
invoked by name :1.26
serial 299
========================================================================
GDBus-debug:Return:
>>>> METHOD ERROR org.freedesktop.PolicyKit1.Error.Failed
message `Cannot determine session the caller is in'
in response to org.freedesktop.PolicyKit1.Authority.RegisterAuthenticationAgent()
on object /org/freedesktop/PolicyKit1/Authority
to name :1.26
reply-serial 299
[...]
========================================================================
GDBus-debug:Incoming:
<<<< METHOD INVOCATION org.freedesktop.PolicyKit1.Authority.RegisterAuthenticationAgent()
on object /org/freedesktop/PolicyKit1/Authority
invoked by name :1.2402
serial 25
========================================================================
GDBus-debug:Return:
>>>> METHOD RETURN
in response to org.freedesktop.PolicyKit1.Authority.RegisterAuthenticationAgent()
on object /org/freedesktop/PolicyKit1/Authority
to name :1.2402
reply-serial 25
Signed-off-by: David Zeuthen <davidz@redhat.com>
The D-Bus spec mentions exactly what header fields are required for
various message types. Add tests for this as well.
Also disallow empty interfaces for signals since the D-Bus spec says
this is Verboten already.
Signed-off-by: David Zeuthen <davidz@redhat.com>
Also use this in the test cases to check that serialization to and
from both big and little endian works.
Signed-off-by: David Zeuthen <davidz@redhat.com>
We use g_assert() instead of setting the GError because it is a
programming error if the GVariant contains invalid data - see commit
5e6f762d61 for where the last hole in
GVariant was closed.
So if we can trust GVariant to only contain valid data (ignoring the
case where unsafe API such as g_variant_new_from_data() is used), why
g_assert() at all with costly g_utf8_validate() checks? Because a) it
is relatively inexpensive; and b) it helps find bugs such as the one
fixed in commit 5e6f762d61.
If performance is a concern we can play games like introducing
environment variables or other machinery to avoid such "costly"
checks. I doubt it will ever be an issue.
Also replace two "Hmm" TODO item with a static assert - the code that
serializes a gdouble into the D-Bus wire format by treating it as a
guint64 is indeed correct - endianess needs to be taken into account
(see the D-Bus reference implementation for similar code). But we want
to make sure that we're indeed using an architecture/compiler where a
gdouble takes up 8 bytes - hence the assertion.
Signed-off-by: David Zeuthen <davidz@redhat.com>
The g_object_bind_property_with_closures() function should set a
marshaller if the two GClosures don't have one already. This simplifies
the caller code and avoids duplication.
We need to add a new marshaller to the gmarshal.list matching the
signature of the GBindingTransformFunc function.
Spell out "RECEIVED SIGNAL" instead of "SIGNAL" to emphasize this is
about receiving a signal, not emitting one (which is "SIGNAL
EMISSION"). Also make the "arrows" point in the "right" direction
("<<<<" vs ">>>>") - like this:
========================================================================
GDBus-debug:Signal:
<<<< RECEIVED SIGNAL org.freedesktop.DBus.NameOwnerChanged
on object /org/freedesktop/DBus
sent by name org.freedesktop.DBus
and
========================================================================
GDBus-debug:Incoming:
<<<< METHOD INVOCATION org.freedesktop.PolicyKit1.Authority.EnumerateTemporaryAuthorizations()
on object /org/freedesktop/PolicyKit1/Authority
invoked by name :1.2176
Signed-off-by: David Zeuthen <davidz@redhat.com>
Commit 5e6f762d61 (introducing UTF-8
validity checks for GVariant instances containing strsings) actually
uncovered a bug in glib-compile-schemas - a GString was passed when a
C string was expected.
Signed-off-by: David Zeuthen <davidz@redhat.com>
As discussed with Ryan on IRC.
This check is crucial because it guarantees that
g_variant_get_string() will _always_ return valid UTF-8. Except in
cases where the programmer used unsafe API such as
g_variant_new_from_data() and setting @trusted to TRUE.
In fact, this check revealed a flaw in my polkit gdbus port
(lt-polkitd:11632): GLib-CRITICAL **: g_variant_new_string: assertion
`g_utf8_validate (string, len, NULL)' failed
and with this I could easily find the problem by using gdb(1) and
G_DBUS=fatal-warnings.
Without this check we'd pass the non-UTF8 string all the way to the
message bus and the bus would then disconnect us. So instead I was
seeing
g_dbus_connection_real_closed: Remote peer vanished with error:
Underlying GIOStream returned 0 bytes on an async read
(g-io-error-quark, 0). Exiting.
and then SIGTERM as raised by g_dbus_connection_real_closed() and my
polkitd process would exit. This behavior is much harder to debug than
failing early (as this patch implements).
Signed-off-by: David Zeuthen <davidz@redhat.com>
This should make things easier to debug:
g_dbus_connection_real_closed: Remote peer vanished with error:
Underlying GIOStream returned 0 bytes on an async read
(g-io-error-quark, 0). Exiting.
Signed-off-by: David Zeuthen <davidz@redhat.com>
the FdSource was calling g_cancellable_disconnect while holding the
main context lock, which is bad news if the ::cancelled handler is
trying to get that lock to wake up the mainloop...
Bug 586432
Since GSettings got the same functionality and flag in commit ca3b7b75b
GBinding should also have the ability to automatically invert a boolean
value without requiring a custom transformation function.
Since using the function pointer version muddles the memory management
requirements of language bindings, we should implement a GClosure-based
variant on top of g_object_bind_property_full().
https://bugzilla.gnome.org/show_bug.cgi?id=622278
When binding a boolean setting to a boolean property, invert the values.
This avoids the requirement for writing a pair of mapping functions for
this extremely common case.
Add a test.
https://bugzilla.gnome.org/show_bug.cgi?id=625833
