The connectivity is directly derived from the `is_available` variable,
so if that changes, we need to notify of a change in `connectivity` too.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Fixes: #3803
This step is no longer "hidden away in the infrastructure" but now in
the open.
Background: some GLib tests can fail with timeouts because of some
assumptions regarding the temporary directory that don't work out on
macOS. Until this is properly investigated and resolved, the
workaround is to redirect it to a ramdisk.
Also add ORKA_RUNNER variable as the macOS CI infrastructure evolves.
Future changes to the image can be controlled this way.
Fixes https://gitlab.gnome.org/Infrastructure/Infrastructure/-/issues/2091
Regression from 501ff95c. Union member offsets are always 0, but we need
to mark them as 'COMPUTED' otherwise they are not written to the
typelib, which results in gi_field_info_get_offset() returning 0xffff.
Since gi_field_info_get/set_field() cannot check that the offset is
within the size of the struct or union, that means poking into invalid
memory addresses.
This also adds some basic tests for GIFieldInfo which would have caught
this bug.
Closes: #3745
This test specifically checks whether the documented behaviour of
deliberately leaking old special dirs strings (which might still be
pointed to in user code) works.
I haven’t gone back and used this new unit test with an older version of
GLib, but I suspect the ‘deliberate leak’ code hasn’t worked for a
while. See the changes in the previous few commits, which were necessary
to get this unit test to pass.
The previous `test_user_special_dirs()` test has been deleted, as what
it was testing has been entirely subsumed into the new test.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
This introduces no functional changes, it just factors out a helper to
set a mock `user-dirs.dirs` file, so that we can do the same in multiple
tests.
It does add a little more error checking to the helper code though; in
particular it checks that the test is running with
`G_TEST_OPTION_ISOLATE_DIRS`.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Otherwise it isn’t set on every code path, and it’s possible for a
caller to receive `NULL` when they call `g_get_user_special_dir
(G_USER_DIRECTORY_DESKTOP)`, i.e. after calling
`g_reload_user_special_dirs_cache()`.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
It seems it wasn’t behaving as advertised: it was freeing all the old
string values unless they were strcmp-equal to the new ones, in which
case the new ones were discarded.
What’s actually documented is that the old values are always leaked,
unless they’re strcmp-equal to the new ones.
Adjust the code to match the documentation. A unit test will be added in
a following commit.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Found by the oss-fuzz test for this parser,
`fuzzing/fuzz_special_dirs.c`.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
oss-fuzz#445870121
oss-fuzz#445848222
Found with `meson test --setup valgrind`, although I also had to change
relevant lines in `glib/tests/meson.build` temporarily to avoid the
other tests in the file taking forever:
```
'utils' : {
'c_standards': c_standards.keys(),
'args': ['-p', '/utils/user-special-dirs'],
},
```
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
`utils-isolated.c` is meant for testing the behaviour of
`G_TEST_OPTION_ISOLATE_DIRS`, not testing the general behaviour of
`gutils.c`. My mistake for not noticing this at code review time when
the test was added.
This introduces no functional changes, just moves a test around.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Another test isolated.
This does mean moving one of the test cases from the suite out into a
separate suite, as it explicitly relies on running without
`G_TEST_OPTION_ISOLATE_DIRS`, and I think that makes sense. The other
test cases run fine when isolated.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
The load_user_special_dirs function performs no internal locking, which
means that callers must already hold the g_utils_global lock. Since we
mark some getters as unlocked by now, do the same with
load_user_special_dirs to highlight this additional requirement.
Suggested by Michael Catanzaro
Any ASCII character above 0x7F should be treated as UTF-8 in
ghostutils functions because GLib expects host names to be either
punycode encoded or in valid UTF-8 format.
The checks in gutf8.c already treat 0x80 as non-ASCII, but two checks
in ghostutils.c erroneously check for "great than" not "greater than or
equal to".
Clarify this by adding a new macro which is reused by PUNICODE_IS_BASIC
for better documentation in code.
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>
Make sure that results of build functions are stored in singletons to
avoid creating multiple instances which eventually could leak.
Fixes: #3784
(cherry picked from commit 18a7e7b4a2)
Co-authored-by: Tobias Stoeckmann <tobias@stoeckmann.org>
When get_help() gets ready to lay out the help text into columns,
it first goes through and computes the max_width of the strings in
the left column. Problem is, it measures the width of every
available option, whether or not they'll actually be displayed.
Instead, let's use the same criteria used when deciding whether
to display an option, to decide whether or not to account for it
when computing max_width. This way, the layout is sized for the
help that's actually being produced.
Fixes#3781
Always NUL-terminate the data, which g_file_get_contents does as well.
This fixes unnecessary fuzzer warnings.
For further clarification of this requirement, rename the internally
used function.
Fixes: #3783
Do what the comment states and strip all trailing slashes. Also, do not
strip the trailing slash if it's the only character left, i.e. if it
denotes the root directory.
XDG_CONFIG_DIR and HOME can be overridden with test environments. Read
these variables before building them again.
It's not possible to call the getter functions directly because the
caller of load_user_special_dirs already holds a lock and locking again
is undefined behavior and could lead to deadlocks.
Separate the functionality out into unlocked functions which definitely
have to be static to not expose them. Use them while holding the lock.
