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.
