We already validated that the required headers for each type of D-Bus
message were present. However, we didn’t validate that they contained a
variant of the right type. This could lead to functions like
`g_dbus_message_get_path()` returning `NULL` unexpectedly.
This failure could only be hit when using GDBus in peer-to-peer mode, or
with a D-Bus server which didn’t validate the headers itself. The
reference D-Bus server does validate the headers, and doesn’t forward
invalid messages to clients.
Signed-off-by: Philip Withnall <philip@tecnocode.co.uk>
Fixes: #3061
Add test cases that result in lookup of the port via
getservbyname().
As the result depends on "/etc/services", it's not reliably the same on
every system. It requires a workaround.
Commit cf55c31170 added a new test which
uses `ptrace()` to check some `GSubprocess` behaviour. FreeBSD uses
different symbol names for ptrace symbols, and we haven’t tested whether
the test works (and reproduces the failure) on FreeBSD, so skip the test
for now.
Signed-off-by: Philip Withnall <philip@tecnocode.co.uk>
The test case will fail with the
g_assert_false (g_subprocess_get_successful (proc));
assert failing. Without the fix, it'll hit sometimes, but rather
unreliably. When running `meson test --repeat 100`, it'll reproduce
anywhere between the first or much later, but mostly before the 20th
iteration on my system.
Helps: #3071
It's not safe to use setlocale() to mutate the locale in a threaded
program. Lots of other tests still do this, and I'm not putting in the
effort to fix them comprehensively in the absense of actual failures on
CI, but I figured it'd be good to fix the tests that I was touching.
This definitely does not do anything on Linux. I bet it's not needed on
other platforms, either. It's unsafe and may crash; there is no safe way
to mutate the environment in threaded programs.
This is a copy of the existing test_l10n, modified to use LC_TIME
instead of LC_MESSAGES. It's not safe as each call to g_setenv() or
setlocale() could cause the test to crash; there is no safe way to
change a threaded process's environment, and a threaded process's locale
can only be safely changed using uselocale(), not with setlocale().
The calls to g_setenv() are definitely not needed on Linux. I wonder
whether removing these will break the test on other platforms?
The calls to setlocale() should be replaced by a dance of
uselocale() -> duplocale() -> newlocale() -> uselocale() on Linux. But
this is not portable and this is a cross-platform test. We would have to
make the test platform-specific to do this. macOS and at least FreeBSD
provide these functions via xlocale.h, but this isn't portable.
The test was passing fine when `bindir` was equal to `multiarch_bindir`,
but not when they differ.
For example, on a Debian system, `gio-querymodules` is installed to
`/usr/lib/x86_64-linux-gnu/glib-2.0/gio-querymodules` rather than
`/usr/bin/gio-querymodules` as it is on (say) Fedora.
This was causing the pkg-config tests to fail on Debian.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #3045
This reverts commit 004f48f4fc.
Per the discussion on #3356, this change was prompted by a
misunderstanding of ldflags/link_args, and it resulted in various other
packages using glib no longer getting symbols exported. This commit
restores the glib 2.76 behaviour.
Avoid generating more code than needed, so other than continuing using
the generic glib marshallers when possible, define once the custom ones
we need for each file we generate.
The marshallers are then re-used across all the interfaces defined
without duplicating the code size.
This is the same we're doing in code generated by glib-genmarshaller and
what gmarshal does internally.
Since the generated gdbus C code can be considered private too, this is
safe to do, and will allow faster access to GValue objects.
Get rid completely of the usage of the generic marshaller in gdbus
generated code, using instead specific marshallers.
Code is not yet optimized fully since we may still have duplicated
functions to be generated.
Closes: https://gitlab.gnome.org/GNOME/glib/-/issues/3028
We relied on g_cclosure_marshal_generic() to easily generate signal
marshallers, but this relies on inspecting each parameter type with ffi
and this implies a performance hit, other than breaking the stack-frame
unwinder used by Linux perf and so by sysprof.
Given that we know the types we work on, it's easy enough to generate
the marshallers ourself.
Helps with: https://gitlab.gnome.org/GNOME/glib/-/issues/3028
When the gnome test runner executes the tests, the test appear to execute in disk
order. This means it sometimes works and sometimes we see breakage in portal-support-snap
and portal-support-snap-classic.
The issue is that some tests create config files but some don't. If they run
in the wrong order, tests see config files they shouldn't and break.
Fix this by deleting the files after each test run, properly cleaning up after
themselves. The cleanup code is based upon gtestutils.c:rm_rf().
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Since we have a convenience method to add actions let's allow to remove
them just as easily. This makes resource cleanup as simple as initially
adding the entries.
Makes the tests compile using clang with meson directly under
termux on android, this build environment does not approve of
overloading libc symbols.
Fixes: #3008
foo
GTK lost it's '+' suffix back in 2019, according to
<https://mail.gnome.org/archives/gtk-devel-list/2019-February/msg00000.html>
This commit can be re-generated with:
git grep -l GTK+ \
| grep -v -e ^NEWS -e ^glib/tests/collate.c \
| xargs sed -i 's/GTK+/GTK/g'
Most of the changes are in comments and documentation.
The gio/tests/socket-client.c doesn't use GSocketClient, which makes the
filename confusing. What the file actually tests is the GSocket. Rename
it to socket-testclient.c
The corresponding GSocket server test file naming doesn't conflict with other
class names, but rename it to socket-testserver.c for consistency.
Closes#2855
If `async_cancel()` was invoked, it would remove the IO watch source,
which would cause the `g_source_remove()` call at the end of `main()` to
warn about an unknown source ID.
Fix that by handling the source as a pointer instead of a handle.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Since commit c0ca3f99 this test is strictly depending on GDesktopAppInfo
that is not defined or available in macos, so skip the test as we do for
windows.
We could have done this at meson level too, but keeping it this way is
probably a better reminder that this should be adapted for such scenario
one day™
See: https://gitlab.gnome.org/GNOME/glib/-/jobs/2753753
As explained in the previous commit, GNU Coreutils 9.2 changes the behaviour
of `du --bytes` to only count regular files and symlinks.
The previous commit makes the test pass with GNU Coreutils >=9.2, but the
machine running the tests may have an older version, or perhaps even a
reimplementation such as uutils. So we can't rely on the size returned by `du`
to be the consistent across systems any more.
However, the plus side of the new behaviour is that the size reported by `du`
/ `G_FILE_MEASURE_APPARENT_SIZE` is now well-defined across filesystems
(as the sum of the sizes of regular files & symlinks), so we can hardcode it.
Fixes: https://gitlab.gnome.org/GNOME/glib/-/issues/2965
Previously, `-Wl,--export-dynamic` was in `Libs` key of `gmodule-2.0.pc`,
even though `-Wl` is a compiler flag, rather than a linker one.
This caused issues with API reference builds in evolution-data-server,
which passes the output of `pkg-config --libs` through `--ldflags`
argument of `gtkdoc-scan`, which are forwarded unchanged to `ld`:
ld: unrecognized option '-Wl,--export-dynamic'
Let’s move the flag to `Cflags` so that the compiler can deal with it.
https://gitlab.gnome.org/GNOME/evolution-data-server/-/issues/463
This should split the code up into logical blocks a bit better, and make
it a bit easier to see what the test is doing at a glance.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
This makes the exit conditions for each main loop clearer, and
eliminates use of global variables. It introduces no functional changes.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
If the first part of the test takes less than 3s (which is normal), the
timeout for it is not removed, and could spuriously fire during the
second part of the test, causing a false failure.
Instead of relying on source IDs, just use (and explicitly destroy) a
`GSource` for the timeouts.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
The test thought that calling `g_app_info_get()` was a bit of a hack,
but actually it (or calling another `g_app_info_*()` function) is the
right way to use the `GAppInfoMonitor` API.
See the documentation improvements a couple of commits back for details.
The remaining FIXME higher up in the test should probably be fixed by
getting `g_app_info_monitor_get()` to arm the signal. That requires
changes in `g_app_info_monitor_get()` to call `desktop_file_dir_init()`.
That will have to happen another time.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #799
This is put together through git archaeology:
```
git log gio/tests/appmonitor.c
```
The following commits were too trivial to have meaningful copyright:
- 54047080e9
- 4e7d22e268
- f2c1cfe8c7
- f8f344923e
- 3ce00b29ec
- 3468369625
- e9d9edde82
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #1415
This fixes bug #624696.
Incorporates a more recent change from 1dc774a653 to drop the
`g_type_init()` call, and reformats the indentation a bit.
Fixes: #322
They just listed built files. Since the move to Meson, these are all
kept in a separate build directory, not the source tree, so don’t need
to be ignored.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
While we can’t check for any events on it, this at least tests that
creating a file monitor works. It should cover the fix from the previous
commit.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: !3241
This should catch regressions in the critical warning fixed in the
previous commit.
The launch has to have several conditions:
- Session bus is running (to avoid the launch happening via the spawn
codepath)
- Use a non-existent D-Bus name (to trigger a launch error)
- Use a launch context (to hit the critical warning code path)
- Not have a startup ID specified in the platform data — this implies
having an empty launch context
- Use an async launch, as that provides an error handling path
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
The timeout runs for the entire duration of the test, which is a
function that Meson’s test harness already provides for us.
Meson’s timeout can be easily adjusted by a factor to allow for running
tests more slowly under valgrind. The timeout in the code cannot, which
leads to spurious failures like
https://gitlab.gnome.org/GNOME/glib/-/jobs/2645271.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
If the timeout callback was executed, it would remove the timeout
source, leaving the `g_source_remove()` call in the main function with a
dangling source ID.
Fixes commit 73205b8bbd.
Spotted in https://gitlab.gnome.org/GNOME/glib/-/jobs/2645271.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
This fixes:
| ../glib-2.75.3/gio/tests/cxx.cpp: In function 'int main(int, char**)':
| ../glib-2.75.3/gio/tests/cxx.cpp:61:15: error: missing sentinel in function call [-Werror=format=]
| 61 | g_test_init (&argc, &argv, NULL);
if built with musl libc
Signed-off-by: Markus Volk <f_l_k@t-online.de>
This reverts commit 27bee8fe5d.
Inevitably, despite testing the CI multiple times before merging commit
27bee8fe, the CI is now failing again in the `socket` test due to (what
I continue to assume is) the kernel regression:
https://gitlab.gnome.org/martinpitt/glib/-/jobs/2585332
In order to unblock development on `main` expediently, I guess I’ll just
revert the revert.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Reopens: #2879
LLVM objcopy's --strip-all is more aggressive that GNU objcopy --strip-all
and will remove everything that is not actually used. In this case we
see the following error:
`error: 'gio/tests/test_resources.o': Symbol table has link index of 5 which is not a valid index`
Fix this by only removing debug symbols instead of all unused symbols and
sections.
Helps: https://gitlab.gnome.org/GNOME/glib/-/issues/2720
Unlike GNU ld which has a default target architecture, ld.lld is always a
cross-linker and has the same behaviour for all targets. If you don't tell
ld.lld what the target architecture is it can't infer the right ELF flags
for the resulting object file.
```
$ ~/cheri/output/sdk/bin/ld -r -b binary gio/tests/test5.gresource -o gio/tests/test_resources.o -v
LLD 14.0.0 (compatible with GNU linkers)
ld: error: target emulation unknown: -m or at least one .o file required
```
As you can see from the error message it can't infer the target
architecture (you need a least one valid .o file or the -m flag).
If you use the compiler instead of directly invoking the linker it will
pass the appropriate flags:
```
$ ~/cheri/output/sdk/bin/clang -r -Wl,-b,binary gio/tests/test5.gresource -o gio/tests/test_resources.o -v
clang version 14.0.0 (https://github.com/CTSRD-CHERI/llvm-project.git ff66b683475fc44355b2010dbcbe1202d785e6f8)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /home/alexrichardson/cheri/output/sdk/bin
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/10
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/11
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/12
Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/12
Candidate multilib: .;@m64
Selected multilib: .;@m64
"/home/alexrichardson/cheri/output/sdk/bin/ld" --eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 -o gio/tests/test_resources.o -L/usr/lib/gcc/x86_64-linux-gnu/12 -L/usr/lib/gcc/x86_64-linux-gnu/12/../../../../lib64 -L/lib/x86_64-linux-gnu -L/lib/../lib64 -L/usr/lib/x86_64-linux-gnu -L/usr/lib/../lib64 -L/home/alexrichardson/cheri/output/sdk/bin/../lib -L/lib -L/usr/lib -r -b binary gio/tests/test5.gresource
❯ file gio/tests/test_resources.o
gio/tests/test_resources.o: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), not stripped
```
This works for most architectures, but ones that need additional metadata
sections to encode the used ABI, etc. will require a different approach
using .incbin. However, that is a change for another MR.
Partially fixes: https://gitlab.gnome.org/GNOME/glib/-/issues/2720
In case the OS does not support epoll and kqueue, we get the warning:
gio/tests/pollable.c: In function ‘test_pollable_unix_nulldev’:
gio/tests/pollable.c:266:7: warning: unused variable ‘fd’
[-Wunused-variable]
266 | int fd;
Get rid of it.
Signed-off-by: Sergey Bugaev <bugaevc@gmail.com>
Fix the tests, by allocating the structure.
==121338==ERROR: AddressSanitizer: stack-use-after-scope on address 0x7ffe44018610 at pc 0x00000040ff71 bp 0x7ffe440178f0 sp 0x7ffe440178e8
READ of size 8 at 0x7ffe44018610 thread T0
#0 0x40ff70 in test_launch_uris_with_terminal ../gio/tests/desktop-app-info.c:1393
#1 0x7efd97b831e8 in test_case_run ../glib/gtestutils.c:2947
#2 0x7efd97b831e8 in g_test_run_suite_internal ../glib/gtestutils.c:3037
#3 0x7efd97b82d23 in g_test_run_suite_internal ../glib/gtestutils.c:3056
#4 0x7efd97b82d23 in g_test_run_suite_internal ../glib/gtestutils.c:3056
#5 0x7efd97b82d23 in g_test_run_suite_internal ../glib/gtestutils.c:3056
#6 0x7efd97b84189 in g_test_run_suite ../glib/gtestutils.c:3136
#7 0x7efd97b842c5 in g_test_run ../glib/gtestutils.c:2248
#8 0x4055bc in main ../gio/tests/desktop-app-info.c:1901
#9 0x7efd9564a50f in __libc_start_call_main (/lib64/libc.so.6+0x2750f)
#10 0x7efd9564a5c8 in __libc_start_main_alias_1 (/lib64/libc.so.6+0x275c8)
#11 0x4059f4 in _start (/home/elmarco/src/gnome/glib/build/gio/tests/desktop-app-info+0x4059f4)
Address 0x7ffe44018610 is located in stack of thread T0 at offset 128 in frame
#0 0x404d1f in main ../gio/tests/desktop-app-info.c:1823
This frame has 6 object(s):
[48, 52) 'argc' (line 1821)
[64, 72) 'path' (line 1870)
[96, 104) 'argv' (line 1822)
[128, 144) '<unknown>' <== Memory access at offset 128 is inside this variable
[160, 176) '<unknown>'
[192, 288) 'supported_terminals' (line 1825)
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
There’s a kernel bug on the CI machines which is causing this test to
fail all the time and it’s getting my goat.
The test can be re-enabled later (by reverting this commit) when the
kernel on the CI VM host is fixed. I don’t know when that’s going to
happen.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2879
Otherwise if, for whatever reason, the `app` loses its D-Bus name,
`g_application_quit()` is called from `name_was_lost()` before it’s
called from `quit_already()`, and then `quit_already()` does an invalid
read on `app`.
If the name was not meant to be lost at this point in the test, the
subsequent `g_assert_false (name_lost)` will catch that, so this change
shouldn’t cause the test to pass unnecessarily.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
In all these cases we don't really care about running the test file,
while building and basic execution it is relevant.
Also they don't support TAP at all.
Meson supports tap protocol results parsing, allowing us to track better
the tests that are running (and the ones that are actually skipped) without
manually parsing the test output.
However this also implies that using the verbose mode for a test doesn't
show its output by default (unless there are failures).
We cannot use `gvisibility_h` for different visibility header files; you
never know when you're going to refer to the variable again, and
projects might end up needing to retrieve the variable contents—like,
for instance, gobject-introspection using glib as a subproject.
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
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
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
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.
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 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 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>
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>
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
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
