Success and failure tests. This massively increases test coverage for
parsing DNS records, although it doesn’t get it to 100%.
It should now be useful enough to do more fuzzing on, without
immediately getting trivial failures from the fuzzer.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Rather than limiting them to the full length of the answer, which may
include subsequent records.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
This should catch all kinds of invalid records, and correctly report
them as errors.
Heavily based on work by Patrick Griffis in !2134.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Otherwise the code isn’t forwards-compatible, and may be DOSed by
servers returning unknown records, if `G_DEBUG=fatal-warnings` is
enabled for some reason.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
It is possible for `dn_expand()` to fail; if so, it’ll return `-1`,
which will mess up subsequent parsing.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Split out from https://gitlab.gnome.org/GNOME/glib/-/merge_requests/2134
by Philip Withnall so it can be used in advance of HTTPS DNS record
support landing.
Reworked to no longer use test fixtures, as it’s simple enough to build
the response header in each test.
The tests are built on Unix only, as they test the parsing code in
`g_resolver_records_from_res_query()`, which is Unix-specific. The
Windows DNS APIs provide much more structured results which don’t need
parsing.
The SONAME of libutil varies between architectures, so the logic to find
the SONAME of libutil was only correct for native builds (Linux on
Linux), not for cross-builds. The regular expression was also not
sufficiently broad to match the SONAME used on the alpha architecture,
which is apparently libutil.so.1.1.
Instead of screen-scraping the output of ldconfig and using that to
dlopen the library that contains openpty, it seems more reliable to
emit a link-time reference to openpty and let the linker do its job.
It's also less code.
Bug-Debian: https://bugs.debian.org/1007946
Signed-off-by: Simon McVittie <smcv@collabora.com>
These should cover everything to do with returning a value or error from
a `GDBusMethodInvocation` object.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
`property_info` is only ever set for `Get` and `Set` calls, not for
`GetAll`, as it only represents a single property. So this code was
never reachable.
Move it out so that it is reachable.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
When doing an early return from `g_dbus_method_invocation_return_*()`
due to passing in the wrong type (or no return value when one was
expected), the parameters were not correctly sunk and were leaked.
Fix that. A unit test will be added in a following commit.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Coverity CID: #1474536
The public `g_strv_contains()` API didn’t exist at the time this code
was originally written. Now, happily, it does.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
The public `g_strv_contains()` API didn’t exist at the time this code
was originally written. Now, happily, it does.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
When the test has finished writing all the expanded content into the
socket, explicitly close the output stream, which should make the input
stream readable and non-blocking.
The code intended to do this before, but only as a side-effect of
dropping its last reference to `right`. If another reference was being
held to `right` somewhere else, it wouldn’t end up being closed, which
would lead to failures like
https://gitlab.gnome.org/GNOME/glib/-/jobs/1890000:
```
(/var/tmp/gitlab_runner/builds/Ff4WDDRj/0/GNOME/glib/_build/gio/tests/converter-stream:56570): GLib-GIO-DEBUG: 12:56:23.280: GSocketClient: Connection successful!
Bail out! GLib-GIO:ERROR:../gio/tests/converter-stream.c:1042:test_converter_pollable: assertion failed (error == NULL): Resource temporarily unavailable (g-io-error-quark, 27)
stderr:
```
This is a bit of a guess (I’m not sure it’ll fix the intermittent test
error, as I haven’t been able to reproduce that locally), but it’s worth
a try.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
When multiple tests were run in parallel, this would race on its access
to `~/.dbus-keyrings` to authenticate with the D-Bus server, since the
keyring directory was not appropriately sandboxed to the unit test.
Use `G_TEST_OPTION_ISOLATE_DIRS` to automatically isolate each unit
test’s directory usage.
This should hopefully fix the failure seen in
https://gitlab.gnome.org/GNOME/glib/-/jobs/1849524, where the following
was in the log for a test executed in parallel:
```
GDBus-DBUS_COOKIE_SHA1: Deleted stale lock file '/home/user/.dbus-keyrings/org_gtk_gdbus_general.lock'
```
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
When multiple tests were run in parallel, this would race on its access
to `~/.dbus-keyrings` to authenticate with the D-Bus server, since the
keyring directory was not appropriately sandboxed to the unit test.
Use `G_TEST_OPTION_ISOLATE_DIRS` to automatically isolate each unit
test’s directory usage.
This should hopefully fix the failure seen in
https://gitlab.gnome.org/pwithnall/glib/-/jobs/1879558.
```
228/266 glib:gio / gdbus-non-socket FAIL 8.64 s (killed by signal 6 SIGABRT)
…
--- stderr ---
GDBus-DBUS_COOKIE_SHA1: Deleted stale lock file '/home/user/.dbus-keyrings/org_gtk_gdbus_general.lock'
**
GLib-GIO:ERROR:../gio/tests/gdbus-non-socket.c:253:test_non_socket: assertion failed (error == NULL): Exhausted all available authentication mechanisms (tried: EXTERNAL, DBUS_COOKIE_SHA1) (available: EXTERNAL, DBUS_COOKIE_SHA1) (g-io-error-quark, 0)
```
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
If the whole set of tests takes more than 5 seconds, the failure timeout
from the first test could still trigger, causing an incorrect failure.
Ensure the timeout is removed at the end of each test.i
This will hopefully fix the CI failure seen here:
https://gitlab.gnome.org/pwithnall/glib/-/jobs/1879558.
```
204/266 glib:gio / gdbus-auth FAIL 9.21 s (killed by signal 5 SIGTRAP)
…
ok 1 /gdbus/auth/client/EXTERNAL
Bail out! GLib-GIO-FATAL-ERROR: Timeout waiting for client
```
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Now that the leaks are fixed, this test can be run under the sanitizer
again.
This is a partial revert of commit
f378352051.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2312
When destroying `GDBusProxy`s in a custom `GMainContext`, the context
must be iterated enough after finalisation of the proxies that any
pending D-Bus traffic, and the signal subscription data, can be freed.
See the documentation for `g_dbus_connection_signal_unsubscribe()`.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2312
This is quite gross, but it looks like the whole content-type code on
Windows is similar. Pass test_subtype.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
The `ay` property has type `string` (see the generated code) since it’s
not been annotated to force accepting a `GVariant`.
This means the GObject property machinery expects a string, and calls
`g_strdup()` on the passed-in pointer, rather than sinking the
`GVariant`.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2312
It periodically hangs due to the `GDBusConnection` having more than 1
ref (and never losing them), so there’s potentially a leaking ref
somewhere:
```
(/builds/alexander.klauer/glib/_build/gio/tests/gdbus-threading:17767): GLib-GIO-DEBUG: 13:18:12.268: refcount of 0x55fe85b1a260 is not right, sleeping
\# GLib-GIO-DEBUG: refcount of 0x55fe85b1a260 is not right, sleeping
```
Add some more debug output to try and track the problem down.
See: https://gitlab.gnome.org/alexander.klauer/glib/-/jobs/1865968
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
It’s periodically failing on FreeBSD and I can’t reproduce the failure
locally nor work out what it is from the logs:
```
Bail out! GLib-GIO:ERROR:../gio/tests/converter-stream.c:1041:test_converter_pollable: assertion failed (res != -1): (-1 != -1)
stderr:
**
GLib-GIO:ERROR:../gio/tests/converter-stream.c:1041:test_converter_pollable: assertion failed (res != -1): (-1 != -1)
```
Add some more debug output to get the value of `error`, in the hope that
will provide some insight.
See: https://gitlab.gnome.org/GNOME/glib/-/jobs/1866486
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Commit 13c4b9579b seems to have fixed
`network-address` so that it’s reliable everywhere, including on macOS.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #1392
This reverts commit 1ed67a9c44.
It turns out that including options, with their default values, in the
`handle-local-options` signal, which weren’t set on the command line,
breaks some applications.
In particular, it breaks Inkscape, which is the application this commit
was originally meant to fix (a different problem).
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2611
Breaks: #2329
See: !1953
This allows applications to get their value regardless whether glib is a
subproject or pkgconfig:
gio_dep = dependency('gio-2.0')
giomoduledir = gio_dep.get_variable('giomoduledir')
schemasdir = gio_dep.get_variable('schemasdir')
This reverts commit 5aa03882ca.
It fails to compile on newer Meson versions with
`--fatal-meson-warnings` due to:
```
WARNING: Project targeting '>= 0.52.0' but tried to use feature introduced in '0.54.0': variables arg in declare_dependency.
gio/meson.build:833:0: ERROR: Fatal warnings enabled, aborting
```
That happens regardless of the fact that we’ve correctly limited the use
of the `variables` argument to only when building with Meson ≥ 0.56.
Unfortunately Meson can’t statically detect that the argument is
conditional.
Bumping GLib’s Meson dependency is too much work right now, so this MR
unfortunately has to be reverted.
This allows applications to get their value regardless whether glib is a
subproject or pkgconfig:
gio_dep = dependency('gio-2.0')
giomoduledir = gio_dep.get_variable('giomoduledir')
schemasdir = gio_dep.get_variable('schemasdir')
`mock-resolver.c` is a mock implementation of `GResolver` used in the
`network-address` tests. It returns resolver results, and implements
timeouts, as directed by the test calling it.
In particular, it allows the IPv4 and IPv6 resolver results to be
returned using independent delays. This allows code paths which deal
with IPv4 and IPv6 results being returned at different times to be
tested, as the ‘Happy Eyeballs’ spec mandates various hard-coded
timeouts for returning the best results it can in a reasonable
timeframe.
Previously, `mock-resolver.c` implemented the timeouts by handling
`lookup_by_name()` in a `GTask` worker thread, and calling `g_usleep()`
for the timeout. This seemed to cause occasional CI failures, such as
https://gitlab.gnome.org/GNOME/glib/-/jobs/1843454, where a resolver
error would be returned rather than the expected results:
```
ok 52 /network-address/happy-eyeballs/ipv4-error-ipv6-first
\# GLib-GIO-DEBUG: IPv4 DNS error: IPv4 Broken
(/var/tmp/gitlab_runner/builds/Ff4WDDRj/0/GNOME/glib/_build/gio/tests/network-address:18428): GLib-GIO-DEBUG: 09:03:08.587: IPv4 DNS error: IPv4 Broken
Bail out! GLib-GIO:ERROR:../gio/tests/network-address.c:586:got_addr: assertion failed (error == NULL): IPv4 Broken (g-io-error-quark, 24)
stderr:
**
GLib-GIO:ERROR:../gio/tests/network-address.c:586:got_addr: assertion failed (error == NULL): IPv4 Broken (g-io-error-quark, 24)
```
While I’ve been unable to reproduce these failures locally, I suspect
they might be down to thread spawning occasionally taking long enough on
a CI runner to change the ordering of the timeouts, such that the ‘Happy
Eyeballs’ algorithm returns a different set of results from what the
test expects.
So, this commit rewrites part of `mock-resolver.c` to implement timeouts
in the main thread, rather than in a worker thread. That should
eliminate the delays in spawning threads, and should mean that the
timeout sources in `mock-resolver.c` are attached to the same
`GMainContext` as those from the ‘Happy Eyeballs’ algorithm which are
monitoring them, so a total order over the timeouts can be guaranteed.
Of course, I might be completely wrong since this is just a guess and I
can’t properly test it since I can’t reproduce the failure. Worth a try.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
The test results weren’t being freed.
This makes the `network-address` test clean under memcheck for me.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
If these struct members aren't available, we can be more like an
abstraction layer by falling back to yielding 0.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Test failures were previously ignored on macOS because there are 12
tests which consistently fail (and have not yet been fixed, because
there are no regularly active macOS maintainers for GLib; you could help
here!).
However, this means that new test failures can’t be spotted.
So, explicitly mark those 12 tests as `should_fail` on macOS, and then
make other test failures cause failure of the CI run.
We can track the process of fixing those 12 tests on #1392 and #1251.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #1392
As they use `g_test_dbus_*()`, they depend on dbus-daemon, so move them
to the part of the Meson file which lists those tests.
This disables them running on platforms which don’t have `dbus-daemon`
available. Arguably, this should be done by returning an error from
`g_test_dbus_up()` and then calling `g_test_skip()`, so the test is
correctly recorded as having been skipped. But that’s a fix for another
time.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Having compared the debug output, it doesn’t show anything unusual
happening that can’t already be seen from other output, for this test.
This is a partial revert of 8fd71dccc5. The debugging output it added to
other tests may still be useful.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #1929
The retry loop for acquiring the lock for the authentication cookie file
currently tries to acquire the lock for 0.5s, then gives up, assumes the
lock file is stale, and deletes it.
That’s great if the lock file *is* stale because it’s been left there by
a crashed process.
It’s not so great if the lock file just happens to have been there every
time this process checked, because the cookie file is highly contested
while (for example) running lots of parallel unit tests.
Check for that situation by comparing the mtime of the lock file and
continuing to retry if it’s changed.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #1929
