The plugin modules in these tests get statically linked with a separate
copy of GLib so they end up calling vfuncs in their own copy of GLib.
Fixes#1648
We need to enable building the dirent and gnulib sources for clang-cl,
as we are still using the Microsoft-style headers and lib's and CRT.
We need to also do this for the following, for similar reasoning:
-Symbol export (via __declspec(dllexport))
-Dependency discovery without pkg-config files
-long long and ssize_t detection
We do, however, enable the autoptr tests for clang-cl builds. Note that
at this point real MSVC builds are still better supported than clang-cl
builds, and it will likely remain so for at least the near future,
alhtough real MSVC builds of the GTK stack are consumable and are usable
by clang-cl.
Now that we're not calling g_object_run_dispose() indirectly in
g_test_dbus_down() (see commit "Revert "gtestdbus: Properly close server
connections""), the test gdbus-connection-loss is failing with the
message "Bail out! GLib-GIO-FATAL-WARNING: Weak notify timeout, object
ref_count=1". This is because we're holding a reference to the singleton
connection object while calling session_bus_down() in the test's main().
So then we end up waiting for 30 seconds in
_g_object_unref_and_wait_weak_notify() for the GWeakNotify to be
triggered, which never happens.
The fix is to unref the connection before calling session_bus_down().
This is consistent with how other tests work, and is safe because the
only method called on the connection has already errored out, as
asserted by the test.
This reverts commit c37cd19fee.
Now that we've reverted the commit "gtestdbus: Properly close server
connections", g_test_dbus_down() no longer returns early and we no
longer need this workaround. Since the gdbus-names test seems to
properly unref its GDBusConnection objects it's not clear to me why it
needed the sleep to succeed. However even at the time the failure wasn't
reproducible according to this comment[1] so it's probably not worth
spending more effort trying to reproduce it now.
[1] https://gitlab.gnome.org/GNOME/glib/issues/787#note_214235
On Visual Studio, Meson builds modules as xxxx.dll, not libxxxx.dll when
xxxx is specified as the name for the shared_module() build directive.
This means that in the test programs if we expect for libxxxx for the
module name, the test will fail as there is no libxxxx.dll but there is
xxxx.dll. This makes the test program look for the module files
correctly.
This ensures that D-Bus connections established with unix:dir and
unix:path addresses actually work properly. Previously, we only tested
unix:tmpdir and TCP addresses.
unix:dir= addresses are exactly the same as unix:tmpdir= addresses,
already supported by GDBus, except they forbid use of abstract sockets.
This is convenient for situations where abstract sockets are
impermissible, such as when a D-Bus client inside a network namespace
needs to connect to a server running in a different network namespace.
An abstract socket cannot be shared between two processes in different
network namespaces.
Applications could use unix:path= addresses instead, so this is only a
convenience, but there's no good reason not to support unix:dir=.
Currently it is not supported simply because unix:dir= is a relatively
recent addition to the D-Bus spec.
It's somewhat unrealistic to use a GDBusServer without a
GDBusAuthObserver, because most D-Bus servers want to be like the
standard session bus (the owning user can connect) rather than being
like the standard system bus (all users can connect, the server is a
security boundary, and many bugs are security vulnerabilities).
Signed-off-by: Simon McVittie <smcv@collabora.com>
Previously, its tests were being run in the build directory, which is
fine (it should always be writable). If multiple tests were run in
parallel, for example with Meson’s `--repeat` option, their test files
would collide.
Fix that by running each test instance in a separate subdirectory of
`/tmp`.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Helps: #1634
Add a case for when the IPv6 result comes back negative and the IPv4
result is significantly delayed. This is exactly the case that causes
the bug addressed by GNOME/glib!865
It should produce a generic result, but not crash. It was previously
crashing on macOS.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Fixes: #1729
g_assert_*() give more helpful error messages on failure, and aren’t
compiled out by G_DISABLE_ASSERT.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
This was introduced in commit 7846d6154a: g_subprocess_get_identifier()
will return NULL after the subprocess has exited, and the subprocess in
the `noop` test will exit as soon as it has started spawning. So if the
scheduler scheduled the testprog subprocess quickly, descheduled the
parent test process until the testprog exited, then the return value
from g_subprocess_get_identifier() would be NULL.
Move the g_subprocess_get_identifier() test to one which calls testprog
in `sleep-forever` mode, since that is guaranteed not to exit until
killed (which we do later in the test).
Signed-off-by: Philip Withnall <withnall@endlessm.com>
The parent GNetworkAddress contains a shared list of resolved
addresses that is used as a cache for multiple enumerations.
This commit ensures that the cache is only set upon completion of
DNS lookups and only read once by enumerations to avoid being in a
bad state.
Fixes#1771
Some of these have a negative master/slave connotation, and they add no
value. Change or drop them.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
The `monitor` test was originally written to test GFileMonitor with
directories. Over time, `testfilemonitor` acquired units for testing
directories as well, which made the `monitor` test reduntant.
Other GCC-like implementations of ld/objcopy (like LLVM) don’t yet
support the right command line arguments, so can’t compile the test.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.gnome.org/GNOME/glib/issues/1709
This introduces no functional changes, but combines two duplicated lists
and makes the meson.build file a little easier to follow.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Helps: #1711
After repeated local testing, I can’t reproduce failures with them:
meson test --repeat 5000 gdbus-auth
meson test --repeat 5000 gdbus-bz627724
meson test --repeat 5000 gdbus-connection
The FreeBSD failures from pthread calls mentioned in #1614 should
probably manifest as use-after-free for GMutex or pthread_mutex_t on
Linux. Failing that, I haven’t seen any relevant FreeBSD failures on CI
for at least a month, so if it’s not fixed, the chances of debugging are
very low.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.gnome.org/GNOME/glib/issues/1614
Check for RTLD_NEXT being present, and disable the gsocketclient-slow
test if it's absent, since the shlib dependency of that test requires
RTLD_NEXT to function.
This allows the testsuite to be built on Cygwin, which behaves
exactly like UNIX, but doesn't have RTLD_NEXT.
Just skip the test if the unix transport isn’t supported. This means we
get better compilation coverage, and more explicit TAP output saying
that the test is being skipped on unsupported platforms.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
The test performs implicit autolaunching of a bus
and checks if it is connectible.
In build the test is moved from "only non-windows with have_dbus_daemon"
to "anywhere".
This is intentional: actually it doesn't execute any external
binaries on unix (so doesn't require dbus_daemon)
and now has win32 implementation.
The test has some problems that are not problems of test itself,
but are reasoned by current win32 implementation:
- since the implementation uses global win32 kernel objects
with fixed names not depending on g_get_user_runtime_dir or other context
if preexisting bus running by some other libgio-using application
the test would silently pass.
- since the implementation uses problematic time-based synchronization,
that has a race condition between opening and reading mmaped address,
the test may randomly fail (I'd not seen this in practice).
- since the implementation autolaunched process works for 3 seconds
after last client disconnects, the executed subprocess runs for 3 seconds
after test exit, maybe locking the libgio-2.0-0.dll file for that time.
