Test failures were previously ignored on macOS because there are 12
tests which consistently fail (and have not yet been fixed, because
there are no regularly active macOS maintainers for GLib; you could help
here!).
However, this means that new test failures can’t be spotted.
So, explicitly mark those 12 tests as `should_fail` on macOS, and then
make other test failures cause failure of the CI run.
We can track the process of fixing those 12 tests on #1392 and #1251.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #1392
As they use `g_test_dbus_*()`, they depend on dbus-daemon, so move them
to the part of the Meson file which lists those tests.
This disables them running on platforms which don’t have `dbus-daemon`
available. Arguably, this should be done by returning an error from
`g_test_dbus_up()` and then calling `g_test_skip()`, so the test is
correctly recorded as having been skipped. But that’s a fix for another
time.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Having compared the debug output, it doesn’t show anything unusual
happening that can’t already be seen from other output, for this test.
This is a partial revert of 8fd71dccc5. The debugging output it added to
other tests may still be useful.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #1929
The retry loop for acquiring the lock for the authentication cookie file
currently tries to acquire the lock for 0.5s, then gives up, assumes the
lock file is stale, and deletes it.
That’s great if the lock file *is* stale because it’s been left there by
a crashed process.
It’s not so great if the lock file just happens to have been there every
time this process checked, because the cookie file is highly contested
while (for example) running lots of parallel unit tests.
Check for that situation by comparing the mtime of the lock file and
continuing to retry if it’s changed.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #1929
Rather than tracking them with a counter. This should close the race in
tracking the finalisation of the tasks by the task worker thread.
There’s no way to synchronise with that thread as it’s internal to
`g_task_run_in_thread()`.
This should hopefully stop the `debugcontroller` test being flaky.
See https://gitlab.gnome.org/GNOME/glib/-/merge_requests/2486#note_1384102
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
We are matching `<parameter>` as well as `<para>`, and we
end up with broken XML in case the (expanded) description
starts with `<parameter>`.
Fixes: #2601
This allows the controller to explicitly be removed from the bus, in a
way that allows the caller to synchronise with it and know that all
other references to the controller should have been dropped (i.e. after
this method returns, there should be no in-flight D-Bus calls still
holding a reference to the object).
This is needed to be able to guarantee finalisation of the controller in
unit tests (and comparable real-world situations).
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #1190
The resources data is generated for both GCC and MSVC toolchains, even
though we know beforehand which toolchain we're going to compile it for.
By dropping the data duplication we make the generated resources file
faster to compile, especially when dealing with large embedded data,
instead of relying on the C pre-processor to walk the whole file and
discard the branch we're not using.
There shouldn’t be any issues here with empty argv arrays since an empty
`Exec=` line is already checked for. Encode that explicitly with an
assertion.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
This won’t really affect anything, but we might as well fix them to not
crash if called with an empty `argv` by someone (ab)using `execve()`.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
While it’s not usual, it is possible for applications to be called with
an empty `argv` by a process (ab)using `execve()`. Modify the
`GApplication` code example to handle that possibility, so that anyone
copying the example isn’t introducing a bug into their program
immediately.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
If `GDebugControllerDBus` remains as the only, or default,
implementation of `GDebugController`, `dup_default()` cannot work.
`GDebugControllerDBus` requires a `GDBusConnection` at construction
time, which the `GIOModule` construction code can’t provide it.
Either we use a default D-Bus connection (but which one? and how would
it be changed by the user later if it was the wrong one?), or delegate
singleton handling of the `GDebugController` to the user.
The latter approach seems more flexible.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #1190
On Windows, dbus is launched by spawning the gdbus.exe executable on
demand from the gio module. When linked dynamically, the executable
path is guessed relatively to the gio DLL path. But when linked
statically, the only reference path available is the current
executable path. In this case, gdbus.exe is not necessarily in the same
folder as the current executable.
This patch solves the issue using the same algorithm as the one used
with process spawning in glib core source code two commits above.
This is intended to provide a uniform interface for controlling whether
the debug output from an application (or service) is emitted, typically
to journald, but actually to wherever the application chooses to output
it.
The main implementation of `GDebugController` is `GDebugControllerDBus`,
which is intended to be used on Linux. Other implementations may be
added in future for other platforms, or larger applications may want to
provide their own implementation which integrates with their ecosystem.
The `GDebugControllerDBus` implementation exposes a D-Bus interface at
`/org/gtk/Debugging` with a method to enable or disable debug
output at runtime.
This could be used by external harnesses, such as GNOME Builder or
systemd, to give a uniform way to get debug output from an application.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #1190
As with the previous commit, this isn’t needed for GLib’s tests to work
correctly, but is probably needed in other projects which might be
tempted to copy and paste the Meson tooling from GLib.
Inspired by https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/4330
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
This isn’t needed to make the tests any better (it doesn’t really affect
them), but is probably needed for anyone who copies this Meson code in
order to add `glib-compile-resources` support to their project. It’s
pretty unlikely that someone would want to compile *and export* a
resource from a shared library.
Inspired by https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/4334
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Credentials are often used to check peer processes details.
With AF_UNIX sockets on Windows, SIO_AF_UNIX_GETPEERPID can
be used to retrive the peer PID.
We will probably introduce more advanced mechanisms later on, though,
but I am not a Windows API expert.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
On !UNIX, return an error for send_fd() & receive_fd().
(the unixfdmessage unit is not compiled on !UNIX)
The header is installed under the common GIO include directory.
Ensure G_TYPE_UNIX_CONNECTION is registered on all platforms.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
The header is now also installed under the common GIO include directory.
Sorry if it breaks any build, you had to use the correct header path.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Move the header under the common GIO include directory.
Sorry if it breaks any build, you had to use the correct header path.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
They are not allowed in the specification, and can lead to infinite
loops when parsing.
That’s a security issue if your application is accepting D-Bus messages
from untrusted peers (perhaps in a peer-to-peer connection). It’s not
exploitable when your application is connected to a bus (such as the
system or session buses), as the bus daemons (dbus-daemon or
dbus-broker) filter out such broken messages and don’t forward them.
Arrays of zero-length elements are disallowed in the D-Bus
specification: https://dbus.freedesktop.org/doc/dbus-specification.html#container-types
oss-fuzz#41428, #41435Fixes: #2557
Glib cannot be built statically on Windows because glib, gobject and gio
modules need to perform specific initialization when DLL are loaded and
cleanup when unloaded. Those initializations and cleanups are performed
using the DllMain function which is not called with static builds.
Issue is known for a while and solutions were already proposed but never
merged (see: https://gitlab.gnome.org/GNOME/glib/-/issues/692). Last
patch is from version 2.36.x and since then the
"constructor/destructor" mechanism has been implemented and used in
other part of the system.
This patch takes back the old idea and updates it to the last version of
glib to allow static compilation on Windows.
WARNING: because DllMain doesn't exist anymore in static compilation
mode, there is no easy way of knowing when a Windows thread finishes.
This patch implements a workaround for glib threads created by calling
g_thread_new(), so all glib threads created through glib API will behave
exactly the same way in static and dynamic compilation modes.
Unfortunately, Windows threads created by using CreateThread() or
_beginthread/ex() will not work with glib TLS functions. If users need
absolutely to use a thread NOT created with glib API under Windows and
in static compilation mode, they should not use glib functions within
their thread or they may encounter memory leaks when the thread finishes.
This should not be an issue as users should use exclusively the glib API
to manipulate threads in order to be cross-platform compatible and this
would be very unlikely and cumbersome that they may mix up Windows native
threads API with glib one.
Closes#692
The gdbus-codegen tool generates documentation from the XML introspection
description of a D-Bus interface. Currently, only DocBook is supported at
the moment, but not every modern documentation generator can handle that
format. The reStructuredText format is a bit more well-supported,
especially in documentation generators for non-C languages.
Unlike DocBook, we get to make our own structure and conventions for how
we structure the documentation when using reStructuredText.
When parsing a comment we're adding <para> elements ourselves, but the
DocBook generator already wraps any block of text that does not start
with a <para> element with one.
xucred does not provide the peer pid id, but this can be fetched
from the socket LOCAL_PEERPID option. Note that we only support
it when creating the credentials from a local socket, if
the credential comes from a message over a socket the peer
pid id will not be set and -1 will be returned when trying
to get the pid for the credential.
D-Bus reference implementation doesn't require more than the claimed
process SID as part of the AUTH initial data for EXTERNAL.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
