We don't need to do this for connections that were never set up
with the main loop.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=107194
Not all of these tests will be fully valgrind-clean yet (or perhaps
ever), but it's easier to add this to all of them than to think
about it.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=107194
In gcc 8, -Wall -Wextra includes -Wcast-function-type, which warns
about passing an extra (unwanted) parameter to callbacks. Instead
of using g_list_foreach(), open-code the equivalent.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=107349
Reviewed-by: Thiago Macieira <thiago@kde.org>
Also use test_oom() where the relevant lines are changing anyway.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=103600
It seemed like a nice idea at the time, but I now think it's more
confusing than it's worth.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=103600
This test-case is actually in the test for monitoring the bus,
because it's easier to see what's going on there - the error reply
to a rejected broadcast is not visible unless you are monitoring.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Reviewed-by: Thiago Macieira <thiago@kde.org>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=92853
The o.fd.DBus interface needs to remain available on arbitrary object
paths for backwards compatibility, and the Introspectable interface
is genuinely useful, but everything else can be skipped.
This is arguably an incompatible change for the undocumented Verbose
interface, and for the GetAllMatchRules method on the undocumented
Stats interface: previously those were available at all object paths.
Reviewed-by: Philip Withnall <withnall@endlessm.com>
[smcv: Adjust comments, enum order, variable naming as per Philip's review]
Signed-off-by: Simon McVittie <smcv@collabora.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=101256
daemon_pid will still be 0 if any tests were skipped. In particular
this happens during `make installcheck`.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=99825
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
This means we respect the destination keyword in arguments to
BecomeMonitor.
In bus_dispatch(), this means that we need to defer capturing until
we have decided whether there is an addressed recipient; so instead
of capturing once, we capture at each leaf of the decision tree.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=92074
Reviewed-by: Philip Withnall <philip.withnall@collabora.co.uk>
Reviewed-by: Lars Uebernickel <lars@uebernic.de>
This does not directly test the code in the previous commit, but it does
confirm that calling dbus_connection_set_route_peer_messages() is enough
to fix the observed bug.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=90952
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Philip Withnall <philip.withnall@collabora.co.uk>
[smcv: re-worded commit message in response to review]
This makes life easier for frameworks like LAVA that screen-scrape
test results.
g_test_message() is not displayed by default, but each test can be run
with either --tap or --verbose to get these messages displayed.
Reviewed-by: Philip Withnall <philip.withnall@collabora.co.uk>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=89846
Functions like become_monitor() sometimes iterate the main context,
which could leave us with unprocessed messages in f->monitored.
We need to drain that queue of unprocessed messages (setting flags
accordingly, which might meet the loop's exit condition or cause
a break) before we are willing to block in the main context again.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=89222
Reviewed-by: Philip Withnall <philip.withnall@collabora.co.uk>
This includes most of the situations I could think of:
* method call on dbus-daemon and response
* NameOwnerChanged
* NameAcquired, NameLost (although I'm not 100% sure these should
get captured, since they're redundant with NameOwnerChanged)
* unicast message is allowed through
* unicast message is rejected by no-sending or no-receiving policy
* broadcast is allowed through
* broadcast is rejected by no-sending policy (the error reply
is also captured)
* broadcast is rejected by no-receiving policy (there is no error
reply)
* message causing service activation, and the message telling systemd
to do the actual activation
* systemd reporting that activation failed
It does not cover:
* sending a message to dbus-daemon, then provoking a reply, then
dbus-daemon does not allow itself to send the reply due to its
own security policy
This is such an obscure corner case that I'm not even convinced it's
testable without dropping down into lower-level socket manipulation:
dbus-daemon's replies are always assumed to be requested replies,
and replies contain so little other metadata that I think we can
only forbid them by forbidding all method replies. If we do that,
the reply to Hello() won't arrive and the client-side connection will
not become active.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=46787
Reviewed-by: Philip Withnall <philip.withnall@collabora.co.uk>
