I noticed this when running the test on an Arm Morello system where varargs
have bounds. g_variant_new() was trying to read an integer using va_arg(),
but since there was no argument it resulted in a bounds errors there.
On most other architectures this will just read whatever value is contained
in the next argument register and is not something that ASan can detect, so
it never resulted in test failures.
When a cancellable is cancelled when we call g_cancellable_connect we
used to immediately call the provided callback, while this is fine we
actually had race in case the cancellable was about to be reset or in
the middle of a cancellation.
In fact it could happen that when we released the mutex, another thread
could reset the cancellable just before the callback is actually called
and so leading to call it with g_cancellable_cancelled() == FALSE.
So to handle this, make disconnect and reset function to wait for
connection emission to finish, not to break their assumptions.
This can be tested using some "brute-force" tests where multiple threads
are racing to connect and disconnect while others are cancelling and
resetting a cancellable, ensuring that all works as we expect.
This solves problems with validating untrusted inputs from D-Bus, where
invalid numbers of added and removed menu entries, and positions, could
be specified.
Original patch from
https://bugzilla.gnome.org/show_bug.cgi?id=728733#c7, tweaked by Philip
Withnall to add a few code comments and make
`G_MENU_EXPORTER_MAX_SECTION_SIZE` public so callers can check their
inputs against it if they want. Also tweaked to use `g_warning()` instead
of the nonexistent `g_dbus_warning()`.
Fixes: #861
If it takes one more `GMainContext` cycle than expected for the
`activate` signals to be handled, the `GApplication` under test can be
released too early, and the test will fail due to not seeing a high
enough value of `n_activations`.
Hopefully avoid that by moving the release to a low priority idle
callback.
This fix is only hopeful because I’ve only been able to reproduce the
failure on FreeBSD CI and not locally.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2835
The timeout is just to stop the test hanging forever, so there’s no need
for it to be so short. It’s caused at least one spurious CI failure:
https://gitlab.gnome.org/GNOME/glib/-/jobs/2445023.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2837
GDesktopAppInfo never failed in the most simple of the cases: when a
desktop file or a command line app info was pointing to an invalid
executable (for the context).
The reason for this is that we're launching all the programs using
gio-launch-desktop which will always exist in a sane GLib installation,
and thus our call to execvp won't ever fail on failure.
This was partially mitigated by not allowing to create a desktop app
icon using a non-existent executable (even if not fully correctly) but
still did not work in case a custom PATH was provided in the launch
context.
To avoid this, use g_find_program_for_path() to find early if a program
that we're about to launch is available, and if it's not the case return
the same error that g_spawn_async_with_fds() would throw in such cases.
While this is slowing a bit our preparation phase, would avoid to leave
to the exec function the job to find where our program is.
Add tests simulating this behavior.
We used to launch applications with terminals using the normal program
finder logic that did not consider the context path nor the desktop file
working dir. Switch to g_find_program_for_path() to find terminals so we
can ensure that both conditions are true.
Update tests to consider this case too.
The platform data comes from the parent process, which should normally
be considered trusted (if we don’t trust it, it can do all sorts of
other things to mess this process up, such as setting
`LD_LIBRARY_PATH`).
However, it can also come from any process which calls `CommandLine`
over D-Bus, so always has to be able to handle untrusted input. In
particular, `v`-typed `GVariant`s must always have their dynamic type
validated before having values of a static type retrieved from them.
Includes unit tests.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #1904
They come from an external process, so they must be validated.
In particular, it’s always easy to forget to validate the type of a
`GVariant`, and just try to get the stored value using a well-known
type; but that’s a programming error if the `GVariant` actually stores a
different type. Always check the variant type first if loading from a
`v`.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #1904
These actions are activated as a result of receiving the `ActionInvoked`
signal from `org.freedesktop.Notifications`. As that’s received from
another process over D-Bus, it’s feasible that it could be malformed.
Without validating the action and its parameter, assertions will be hit
within the `GAction` code.
While we should be able to trust whatever process owns
`org.freedesktop.Notifications`, it’s possible that’s not the case, so
best validate what we receive.
Includes unit tests.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #1904
This test is fairly pointless, but puts the infrastructure in place for
adding more tests for `GFdoNotificationBackend` in upcoming commits.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #1904
Invoking an action on a notification should remove it (by default,
unless the `resident` hint is set, but GLib doesn’t currently support
that).
If, somehow, an invalid action is invoked on the notification, that
shouldn’t cause it to be removed though, because no action has taken
place. So change the code to do that.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
As with the previous commit, the arguments to `ActivateAction` have to
be validated before being passed to `g_action_group_activate_action()`.
As they come over D-Bus, they are coming from an untrusted source.
Includes unit tests for all D-Bus methods on `GApplication`.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #1904
The action name, parameter and new state are all controlled by an
external process, so can’t be trusted. Ensure they are validated before
being passed to functions which assert that they are correctly typed and
extant.
Add unit tests.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #1904
Some applications (eg., gnome-photos) really want a large thumbnail,
if one can be created. Simply falling back to a smaller one (probably
created by an old nautilus), without giving the application a chance
to create a bigger thumbnail, is undesirable because they will appear
fuzzy.
Therefore, at separate attribute sets for all the thumbnail sizes
that are supported in the spec: normal/large/x-large/xx-large.
The old attribute will now return by default the biggest available, as
it used to be, but also including the x-large and xx-large cases.
Co-Authored-by: Marco Trevisan <mail@3v1n0.net>
Fixes: #621
In case they differ from the defaults, we probably want to ignore them
when listing filesystems which are interesting to the user.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
This reworks commit 20e1508e6e, for two
reasons:
- Upstream dbus.git now does the same (although this isn’t yet reflected
in the online version of the D-Bus Specification); see
https://gitlab.freedesktop.org/dbus/dbus/-/merge_requests/209.
- It allows local-prefix (e.g. jhbuild) builds of GLib to build in a
custom prefix while still interacting with system services using the
system-wide `/run` directory. To do so, pass `-Druntime_dir=/run` to
meson configure.
As documented in the `NEWS` file in
https://gitlab.freedesktop.org/dbus/dbus/-/merge_requests/209, it’s only
valid to use `/run` – rather than `/var/run` – for D-Bus if the two
paths are interoperable. i.e. `/var/run` should be a symlink to `/run`,
and the D-Bus daemon should be configured to put its socket there.
This commit deliberately doesn’t introduce a special `system_socket`
configure option for specifying where the D-Bus system socket lives, as
that would only be useful for a distribution which sets `runstatedir` to
something other than `/var/run` or `/run`, which seems unlikely. We
could add such an option in future, though, if a distribution comes
forward with such a requirement.
See discussion on
https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3095#note_1605502.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
under cygwin socklen_t is signed which leads to warnings like:
warning: comparison of integer expressions of different signedness:
‘long unsigned int’ and ‘socklen_t’ {aka ‘int’} [-Wsign-compare]
In both cases we compare against some small fixed sizes, so cast them
to socklen_t.
cygwin defines socklen_t as int, unlike everywhere else where it is uint32_t (afaics),
so signed vs unsigned.
The recently added -Werror=pointer-sign in 4353813058
makes the build fail under cygwin now with something like:
error: pointer targets in passing argument 5 of ‘getsockopt’ differ in signedness [-Werror=pointer-sign]
This changes guint to socklen_t where needed for getsockname, getpeername and getsockopt.
Do not search in path for snapctl to avoid it to be potentially
overridden by changing the PATH env variable.
Still allow testing by using an ifdef to check if we're building for the
test files or not.
Test all the snap cases and the unknown sandbox one.
We need to use different test processes as we initialize the portal
type early enough that it can't be changed later.
This is of particular use in the gsettings backend, which is currently using
dconf for all snaps.
Fully confined snaps should use the keyfile backend, as Flatpaks do.
Co-Authored-by: Marco Trevisan <mail@3v1n0.net>
Classic snaps are just a kind of packages with no sandbox at all, so
there's no point to mark them as sandboxed.
In this way we can just do IO checks once without having to multiply
them.
Co-Authored-by: Robert Ancell <robert.ancell@canonical.com>
This reverts commit 7e3e591d43.
The freedesktop SDK, which is used by gnome-build-meta, only has Meson
0.63. Bumping GLib’s Meson dependency to 0.64 means that, at the moment,
GLib is not buildable in gnome-build-meta and hence can’t be tested in
nightly pipelines against other projects, etc.
That’s bad for testing GLib.
It’s arguably bad that we’re restricted to using an older version of
Meson than shipped by Debian Testing, but that’s a separate discussion
to be had.
Revert the Meson 0.64 dependency until the freedesktop SDK ships Meson ≥
0.64. This also means reverting the simplifications to use of
`gnome.mkenum_simple()`.
See https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3077#note_1601064
This reverts commit 19353017a7.
The freedesktop SDK, which is used by gnome-build-meta, only has Meson
0.63. Bumping GLib’s Meson dependency to 0.64 means that, at the moment,
GLib is not buildable in gnome-build-meta and hence can’t be tested in
nightly pipelines against other projects, etc.
That’s bad for testing GLib.
It’s arguably bad that we’re restricted to using an older version of
Meson than shipped by Debian Testing, but that’s a separate discussion
to be had.
Revert the Meson 0.64 dependency until the freedesktop SDK ships Meson ≥
0.64. This also means reverting the simplifications to use of
`gnome.mkenum_simple()`.
See https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3077#note_1601064
This reverts commit 756b424cce.
The freedesktop SDK, which is used by gnome-build-meta, only has Meson
0.63. Bumping GLib’s Meson dependency to 0.64 means that, at the moment,
GLib is not buildable in gnome-build-meta and hence can’t be tested in
nightly pipelines against other projects, etc.
That’s bad for testing GLib.
It’s arguably bad that we’re restricted to using an older version of
Meson than shipped by Debian Testing, but that’s a separate discussion
to be had.
Revert the Meson 0.64 dependency until the freedesktop SDK ships Meson ≥
0.64. This also means reverting the simplifications to use of
`gnome.mkenum_simple()`.
See https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3077#note_1601064
Meson now uses find_program() to get glib-mkenum from glib instead of
from system. That was already fixed at least in >=0.60 which is our
current minimum requirement.
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>
Because Meson complains about using `configure_file(copy: true)`.
Includes improvements by Xavier Claessens.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
This is deprecated since Meson 0.62.0, since Meson does this
automatically for us.
This fixes a Meson configure warning.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
It sometimes fails under valgrind, and is pointless: if the test is
wedged, it’s better to catch that with the timeout at the level of
`meson test`, which can be tailored (using `-t`) to the test environment
and wrapper.
See https://gitlab.gnome.org/GNOME/glib/-/merge_requests/2961#note_1600072
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Instead, iterate the `GMainContext` directly. This allows tests on
asynchronously returned values to be done in the actual test function,
rather than a callback, which should make the tests a little clearer.
This introduces no functional changes.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
This makes the code a little easier to understand and allows the kernel
a little bit more leeway in scheduling the callback, which is fine
because we don’t need high accuracy here.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
`g_notification_backend_new_default()` adds a reference on
`backend->dbus_connection` (if non-`NULL`), but nothing ever unreffed
that.
Fix that by adding a dispose method.
In practice this is not really a problem, because the notification
backend is held alive by a `GApplication`, which lives as long as the
process. It’ll be a problem if someone is to ever add unit tests for
`GNotificationBackend`s though. So let’s fix it.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Add a few missing introspection annotations too.
This doesn’t change any of the ownership handling behaviour, just
documents what’s there. What’s there seems to be correct, to the extent
that I can see.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
The code is correct, but from a quick read-through it wasn’t entirely
clear to me how it handled floating `GVariant`s in object state or the
`parameter` argument.
Add an assertion and some comments to hopefully clarify things a little.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Do not use can_run_host_binaries() as it returns true even though
custom_target() does not currently correctly wrap target-built
tool binaries with exe_wrapper so they can be run on the host.
See https://github.com/mesonbuild/meson/issues/11029
Building GLib 2.75.0 on Linux adds various inotify-related internal
symbols to the ABI, which doesn't seem to have been intentional.
I went through the other libraries in the build system, and it looks
as though the BSD kqueue backend would have the same problem.
GNU symbol visibility probably doesn't do anything for gio/win32, but
for completeness I've set that to use hidden symbols too, on the basis
that it'll be easier to get this right if we're consistent.
Resolves: https://gitlab.gnome.org/GNOME/glib/-/issues/2811
Signed-off-by: Simon McVittie <smcv@collabora.com>
This typically indicates a bug in the program, where a GTask has been
created, but a bug in the control flow has caused it to not return a
value.
There is one situation where it might be legitimate to finalise a GTask
without returning: if an error happens in your *_async() start function
after you’ve created a GTask, but before the async operation returns to
the main loop; and you report the error using g_task_report_*error()
rather than reporting it using the newly constructed GTask.
Another situation is where you are just using GTask as a convenient way
to move some work to another thread, without the complexity of creating
and running your own thread pool. GDBus does this with
g_dbus_interface_method_dispatch_helper(), for example.
In most other cases, it’s a bug. Emit a debug message about it, but not
a full-blown warning, as that would create noise in the legitimate
cases.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
the gio dbus codegen test has 10 test cases in it.
Each test case is given 100 seconds to complete.
That is far longer than they should need.
Furthermore, the entire test is only given 60s
to complete.
This commit makes the internal timeout more consistent
with the external timeout, by giving each of the 10
test cases 6 seconds instead of 100s.
That’s what xdgmime uses for zero-sized files (see `XDG_MIME_TYPE_EMPTY`).
Historically, GLib explicitly used `text/plain` for empty files, to
ensure they would open in a text editor. But `text/plain` is not really
correct for an empty file: the content isn’t text because there is no
content. The file could eventually become something else when written
to.
Text editors which want to be opened for new, empty files should add
`application/x-zerosize` to their list of supported content types.
Users who want to set a handler for `application/x-zerosize` on their
desktop should use
```sh
gio mime application/x-zerosize # to see the current handler
gio mime application/x-zerosize org.gnome.gedit.desktop # to set it
```
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2777
`HAVE_COCOA` should be used only in the places where we’re actually
depending on the Cocoa toolkit. It should not be used as a general way
of detecting building on a Darwin-based OS such as macOS.
Conversely, there are a few places in the code where we do want to
specifically detect the Cocoa toolkit (and others where we specifically
want to detect Carbon), so keep `HAVE_COCOA` and `HAVE_CARBON` around.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2802
This reverts commit 476e33c3f3.
We’ve decided to remove `G_OS_DARWIN` in favour of recommending people
use `__APPLE__` instead. As per the discussion on #2802 and linked
issues,
* Adding a new define shifts the complexity from “which of these
platform-provided defines do I use” to “which platform-provided
defines does G_OS_DARWIN use”
* There should ideally be no cases where a user of GLib has to use
their own platform-specific code, since GLib should be providing
appropriate abstractions
* Providing a single `G_OS_DARWIN` to cover all Apple products (macOS
and iOS) hides the complexity of what the user is actually testing:
are they testing for the Mach kernel, the Carbon and/or Cocoa user
space toolkits, macOS vs iOS vs tvOS, etc
Helps: #2802
Some of GLib's unit tests are under an apparently GLib-specific
permissive license, vaguely similar to the BSD/MIT family but with the
GPL's lack-of-warranty wording. This is not on SPDX's list of
well-known licenses, so we need to use a custom license name prefixed
with LicenseRef if we want to represent this in SPDX/REUSE syntax.
Most of the newer tests seem to be licensed under LGPL-2.1-or-later
instead.
Signed-off-by: Simon McVittie <smcv@collabora.com>
In g_proxy_resolver_lookup_async() we have some error validation that
detects invalid URIs and directly returns an error, bypassing the
interface's lookup_async() function. This is great, but when the
interface's lookup_finish() function gets called later, it may assert
that the source tag of the GTask matches the interface's lookup_async()
function, which will not be the case.
As suggested by Philip, we need to check for this situation in
g_proxy_resolver_lookup_finish() and avoid calling into the interface
here if we did the same in g_proxy_resolver_lookup_async(). This can be
done by checking the source tag.
I added a few new tests to check the invalid URI "asdf" used in the
issue report. The final case, using async GProxyResolver directly,
checks for this bug.
Fixes#2799
Similar to g_source_set_static_name, this avoids
strdup overhead for debug-only information in
possibly hot code paths.
We also add a macro wrapper for g_task_set_name that
uses __builtin_constant_p to decide whether to use
g_task_set_name or g_task_set_static_name.
We already set names on most sources, this
one was just forgotten. This lets us set
a static name, and prevents g_task_attach_source
from setting a non-static one.
