If the build/test machine is slow, heavily-loaded or otherwise
inconvenienced, it might take a few seconds for the signal to be sent
by the subprocess, received by the message bus, re-broadcasted by the
message bus and received by the test code. Wait a few more seconds
before giving up.
If this test is successful, increasing this timeout will not slow it
down: we stop waiting for the signal as soon as we receive it. This will
only make any difference if the test would have failed.
Signed-off-by: Simon McVittie <smcv@debian.org>
We have two things happening in parallel:
1. The GDBus worker thread writes out an AddMatch call to the socket,
the message bus reads that method call from the other end of the
socket, and the message bus responds by adding the match rule
for the signal subscription
2. The main thread forks, and the child execs
gdbus-connection-flush-helper, which sends the signal that we are
expecting; the message bus receives that signal, and broadcasts it
to subscribers, if any
Normally (1.) wins the race because exec'ing a child process is more
time-consuming than IPC, and the test passes.
However, it is possible for (2.) to win the race. If so, we will never
receive the expected signal (because it was received by the message bus
before the AddMatch() method call, so at the time it was received, the
test was not yet a subscriber); the test waits until the timeout and
then gives up, and the test fails.
For whatever reason, Debian's s390x buildd seems to be reliably failing
this test since this week, having previously passed. I don't know what
changed. I can (very rarely) reproduce the race condition described
above on a developer-accessible s390x machine by repeatedly running the
/gdbus/connection/flush test in a loop.
Bug-Debian: https://bugs.debian.org/1115617
Signed-off-by: Simon McVittie <smcv@debian.org>
This makes no functional changes, but does tidy the code up a bit and
means `g_steal_handle_id()` gets a bit more testing.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
This is a spiritual follow-up to commit 8cff531520, which
added `G_TEST_OPTION_ISOLATE_DIRS` to the `gdbus-connection-flush` test
to avoid its D-Bus cookie lock file from being erroneously deleted by
other tests running in parallel.
The same failure mode could affect any of the other D-Bus tests which
connect to a bus. As an easy fix, enable `G_TEST_OPTION_ISOLATE_DIRS`
for all of them.
The only test it’s not (yet) enabled for is `gdbus-address-get-session`
as that messes around with `XDG_RUNTIME_DIR` to test finding the session
bus. It might be possible to use `G_TEST_OPTION_ISOLATE_DIRS` with it,
but that would take longer than I have right now.
In any case, the more tests (which try to connect to a bus) that this is
enabled for, the lower the chances of spurious test failure due to them
conflicting over shared resources.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Add SPDX license (but not copyright) headers to all files which follow a
certain pattern in their existing non-machine-readable header comment.
This commit was entirely generated using the command:
```
git ls-files gio/tests/*.c | xargs perl -0777 -pi -e 's/\n \*\n \* This library is free software; you can redistribute it and\/or\n \* modify it under the terms of the GNU Lesser General Public/\n \*\n \* SPDX-License-Identifier: LGPL-2.1-or-later\n \*\n \* This library is free software; you can redistribute it and\/or\n \* modify it under the terms of the GNU Lesser General Public/igs'
```
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #1415
On Unix platforms, wait() and friends yield an integer that encodes
how the process exited. Confusingly, this is usually not the same as
the integer passed to exit() or returned from main(): conceptually it's
an integer encoding of this tagged union:
enum { EXITED, SIGNALLED, ... } tag;
union {
int exit_status; /* if EXITED */
struct {
int terminating_signal;
bool core_dumped;
} terminating_signal; /* if SIGNALLED */
...
} detail;
Meanwhile, on Windows, wait statuses and exit statuses are
interchangeable.
I find that it's clearer what is going on if we are consistent about
referring to the result of wait() as a "wait status", and the value
passed to exit() as an "exit status".
GSubprocess already gets this right: g_subprocess_get_status() returns
the wait status, while g_subprocess_get_exit_status() genuinely returns
the exit status. However, the GSpawn family of APIs has tended to
conflate the two.
Confusingly, g_spawn_check_exit_status() has always checked a wait
status, and it would not be correct to pass an exit status to it; so
let's deprecate it in favour of g_spawn_check_wait_status(), which
does the same thing that g_spawn_check_exit_status() always did.
Code that needs backwards-compatibility with older GLib can use:
#if !GLIB_CHECK_VERSION(2, 69, 0)
#define g_spawn_check_wait_status(x) (g_spawn_check_exit_status (x))
#endif
Signed-off-by: Simon McVittie <smcv@collabora.com>
It occasionally fails in CI with output like:
```
196/274 glib:gio / gdbus-connection-slow FAIL 0.54 s (killed by signal 6 SIGABRT)
--- command ---
G_TEST_BUILDDIR='/builds/pwithnall/glib/_build/gio/tests' G_TEST_SRCDIR='/builds/pwithnall/glib/gio/tests' GIO_MODULE_DIR='' /builds/pwithnall/glib/_build/gio/tests/gdbus-connection-slow
--- stdout ---
\# random seed: R02S4eb186e89e2472eedd11538b37192543
1..2
\# Start of gdbus tests
\# Start of connection tests
Bail out! GLib-GIO:ERROR:../gio/tests/gdbus-connection-slow.c:98:test_connection_flush: assertion failed (error == NULL): Child process killed by signal 11 (g-exec-error-quark, 19)
--- stderr ---
**
GLib-GIO:ERROR:../gio/tests/gdbus-connection-slow.c:98:test_connection_flush: assertion failed (error == NULL): Child process killed by signal 11 (g-exec-error-quark, 19)
cleaning up pid 12991
```
which is not very helpful. Add some more debug output to print the
stdout and stderr of the child process, to hopefully give an insight
into why it’s dying with signal 11 (sigsegv).
I can’t reproduce the sigsegv locally.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
All those logging functions already add a newline to any message they
print, so there’s no need to add a trailing newline in the message
passed to them.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Reviewed-by: nobody
The test /gdbus/connection/large_message waits for a dbus name to appear.
The dbus name is created by a another process executed in the background.
If for some reason this fails, the test will likely wait forever.
This will avoid this situation by making the test fail if the dbus service
has not appeared after 10 seconds.
https://bugzilla.gnome.org/show_bug.cgi?id=698981
Very many testcases, some GLib tools (resource compiler, etc) and
GApplication were calling g_type_init().
Remove those uses, as they are no longer required.
https://bugzilla.gnome.org/show_bug.cgi?id=686161
Many (if not "almost all") programs that spawn other programs via
g_spawn_sync() or the like simply want to check whether or not the
child exited successfully, but doing so requires use of
platform-specific functionality and there's actually a fair amount of
boilerplate involved.
This new API will help drain a *lot* of mostly duplicated code in
GNOME, from gnome-session to gdm. And we can see that some bits even
inside GLib were doing it wrong; for example checking the exit status
on Unix, but ignoring it on Windows.
https://bugzilla.gnome.org/show_bug.cgi?id=679691