Previously the len passed to g_socket_address_new_from_native() was only
for IPv4 addresses and the constructor would fail.
This was reported and discussed here:
fe0139ee98 (note_2581394)
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
Rather than reporting an error via a new `GTask`, report it via the
`GTask` we’ve already created. This avoids a critical warning about
destroying the `GTask` without returning a result.
Also ensure to disconnect the D-Bus signal subscription first, to avoid
an assertion failure in `call_data_free()`.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Fixes: #3798
We have some (deprecated) methods that technically still return
transfer-full instances of GTypeClass's and GTypeInterface's.
The introspection scanner cannot generate bindings for them though since
it does not know how to manage their lifecycle, and we end up skipping
these symbols.
This is breaking some language bindings, and in particular gjs [1] and
lua-lgi, that were using the .ref methods.
While we should not use deprecated functions in the language bindings,
these symbols should still be introspected.
[1] https://gitlab.gnome.org/GNOME/gjs/-/issues/711
Partially reverts commit cad84d5e27.
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
