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>
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.
g_assert_*() give more informative failure messages, and aren’t compiled
out when building with G_DISABLE_ASSERT.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
g_assert_*() give more informative failure messages, and aren’t compiled
out when building with G_DISABLE_ASSERT.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
In order to allow GLib itself to be built with G_DISABLE_ASSERT defined,
we need to explicitly undefine it when building the tests, otherwise
g_test_init() turns into an abort.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Fixes: #1708
g_assert_*() give more informative error messages on failure, and can’t
be disabled by G_DISABLE_ASSERT.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Commit f975858e86 removed the NULL check in g_cancellable_cancel() by
accident which makes it crash when called with NULL.
Add the check back and add a test so this doesn't happen again.
Fixes#1710
Don’t pollute the build directory with files generated by running the
test.
Note that there are still other tests in the gsettings.c test suite
which use the build directory, but fixing them is a bit more involved
than I have time for right now. This is a step in the right direction.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
This essentially reverts commit
cffed58737.
The preceding two commits have fixed the test so it’s no longer flaky.
The following command gives 5000 passes in a row for me:
meson test -C /opt/gnome/build/glib/ socket-service --repeat 5000
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Fixes: #1679
It’s occasionally possible for the cancellation of the service to happen
before connection_cb() gets scheduled in the other thread. The
locking/unlocking order of mutex_712570 requires:
• test_threaded_712570(): lock mutex
• test_threaded_712570(): start wait loop
• connection_cb(): lock mutex
• test_threaded_socket_service_finalize(): unlock mutex
• test_threaded_712570(): end wait loop
• test_threaded_712570(): unlock mutex
Fix that by quitting the main loop once connection_cb() has been called
(i.e. once the server thread has received the incoming connection
request), rather than just after the client thread (main thread) has
sent a connection request.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Helps: #1679
On about 1 in 3 test runs, the socket-service would fail with the
ref_count assertion in connection_cb() failing (the ref_count would be 3
rather than the expected 2).
This was happening because the GTask from
g_socket_listener_accept_socket_async() now always takes at least one
main context iteration to return a result (whereas before
6f3d57d2ee it might have taken zero), but
the ref_count can drop below 3 before the process of returning a result
starts. During the process of returning a result, the ref_count
temporarily increases again, which is what was breaking the test.
Fix this by waiting for one more main context iteration. This is a bit
of a hack, but the real fix would be to expose the outstanding_accept
boolean from GSocketService as public API (which the test can
interrogate), and that seems too much like exposing internal state.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Helps: #1679
Compilers get confused when variables are initialized by a function by
taking them as reference in an out argument; this, coupled with the fact
that C does not initialize variables by default, most commonly results
in a "maybe uninitialized" compiler warning.
When testing as root, changing the permissions of the keyfile will have
no effect on the writability since root bypasses these permissions. See
path_resolution(7). Skip the test in this case.
g_assert_*() give more informative error messages, and aren’t compiled
out when building with G_DISABLE_ASSERT.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
getsockname() returns the address that the socket was bound to.
If it was bound to INADDR_ANY, getsockname() will stubbornly return INADDR_ANY
(and someport - that one is valid).
Subsequent connection attempts to INADDR_ANY:someport will fail with winsock.
Actually, it doesn't make even sense to connect to INADDR_ANY at all
(where is the socket connecting to? To a random interface of the host?),
so this is just a straight-up change, without platform-specific ifdefing.
Use loopback instead of INADDR_ANY. To ensure that binding and creation
of INADDR_ANY is still tested, use two addresses: bind to INADDR_ANY,
but connect to loopback, with the port number that we got from the bound
address.
