We don't really need g_socket_send_with_blocking here.
Also, don't leak the GLib socket objects.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=41219
Reviewed-by: Lennart Poettering <lennart@poettering.net>
This avoids spamming ~/.dbus and ~/.dbus-keyrings with filesystem activity
while running the tests.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=41218
Reviewed-by: Lennart Poettering <lennart@poettering.net>
In Unix, the tests listened on both debug-pipe (which is a socketpair,
or a TCP emulation of socketpair on Windows) and a Unix socket.
In the Windows port, the tests were hard-coded to listen on a particular
port, which allowed the dispatch test to connect to that port, as long
as no two tests ran simultaneously (which I don't think was ever guaranteed -
make -j can violate this). That's valid out-of-process, and also
fully-specified, so they only needed one <listen> directive, so the
CMake input only had one.
To make the tests work under CMake on Unix, there was a hack: the string
substituted for the content of the <listen> directive contained
</listen><listen> to get the other address in, which is pretty nasty.
Instead of doing that, I've made both build systems, on both Unix and
Windows, use both debug-pipe and a more normal transport (Unix or TCP).
debug-pipe has a Windows implementation and it's used in
dbus-spawn-win.c, so it'd better work. The use of debug-pipe is now
hard-coded rather than being a configure parameter (there's no reason
to vary it in different builds), and I used TEST_LISTEN as the name of the
Unix/TCP address, because it's a "vague" address (no specific Unix path, no
TCP port), that you can listen on but not connect to.
This in turn means that we can merge the Autoconf .in and CMake .cmake
files, similar to Bug #41033.
You might wonder why I've kept debug-pipe. I did try to get rid of it, but
it turns out that the tests in dispatch.c rely on
dbus_connection_open_private() not blocking, and normal socket
connections block on connect(). Until we fix that by adding an async
version of dbus_connection_open_private(), it won't be safe to have a
test like dispatch.c that "talks to itself", unless it uses a transport
as trivial as debug-pipe in which neither end has to block on the other.
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=41222
Also use EXEEXT in all the service files, even in the automake build
system.
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=41222
As with the optional test-dependencies on GLib and dbus-glib, we make this
a hard dependency if --enable-tests[=yes], but not if --enable-tests=auto.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=37847
Reviewed-by: Will Thompson <will.thompson@collabora.co.uk>
Previously, it'd fail when done twice, because you can't rmdir a
nonexistent directory.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=40004
Reviewed-by: Will Thompson <will.thompson@collabora.co.uk>
INCLUDES is a deprecated way to get the same effect as AM_CPPFLAGS.
It's harmless to add extra -I directories to all the tests, even those
that use neither GLib nor dbus-glib, so we can simplify by setting these
AM_CPPFLAGS for the whole directory.
If we change the default assumption to be that new tests will be
dynamically-linked to libdbus, those tests can be useful for
installcheck or even for installation. Accordingly, explicitly use
new variable $(static_cppflags) for all tests that need static linking.
This is the library used by tests that link libdbus-internal and DBusLoop.
By linking libdbus-internal into it, we can avoid having to repeat that
dependency all over the place - libtool and cmake both know how to follow
recursive dependencies.
In cmake, also use libdbus-testutils for more tests, in preference to
repeating its source files.
These tests get everything they need from the public or internal API of
libdbus-internal.la, and libtool knows how to pull in libraries'
dependencies, so we don't need explicit linking.
spawn-test and break-loader don't actually need test-utils.[ch]
either.
The number of messages is arbitrary; the more messages, the more likely
the crash is. 2000 messages seem to cause it reliably on this laptop,
but I've set it to 10000 to be safe.
Reviewed-by: Colin Walters <walters@verbum.org>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=34393
This is necessary when cross-compiling from Linux to mingw32 and running
the resulting tests under Wine. (This partially works! Some tests fail,
though.)
Reviewed-by: Will Thompson <will.thompson@collabora.co.uk>
This improves clarity, and makes conflicts less likely and merges more
obviously correct.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=34405
Reviewed-by: Will Thompson <will.thompson@collabora.co.uk>
Similar to the previous commit, almost every use of DBusWatch can just
have the main loop call dbus_watch_handle.
The one exception is the bus activation code; it's had a comment
explaining why it's wrong since 2003. We should fix that one day, but for
now, just migrate it to a new _dbus_loop_add_watch_full which preserves
the second-layer callback.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=33342
Reviewed-by: Thiago Macieira <thiago@kde.org>
Instead of supplying 8 tiny wrapper functions around dbus_timeout_handle,
each with a user_data parameter that's a potentially unsafe borrowed
pointer but isn't actually used, we can call dbus_timeout_handle directly
and save a lot of trouble.
One of the wrappers previously called dbus_timeout_handle repeatedly
if it returned FALSE to indicate OOM, but that timeout's handler never
actually returned FALSE, so there was no practical effect. The rest just
ignore the return, which is documented as OK to do.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=33342
Reviewed-by: Thiago Macieira <thiago@kde.org>
