The "/unix-fd/scm" test is quite Unix-specific, the next patch is going
to add a portable test.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Apply --internal to the symbol for the section as well.
Only do this with --external-data, since otherwise gcc
will complain about ignoring the attribute.
This fixes https://gitlab.gnome.org/GNOME/gtk/-/issues/4598
See !2214 for motivation. It doesn't work properly anymore, and the TLS
versions of these functions were already deprecated. Sadly, I missed the
DTLS versions.
Fixes#2646
Use a prefix matching the binary, rename the test "scm", as it involves
SocketControlMessage.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
This will help static analysers which think that the type of
`priv->proxy_address` could potentially change between freeing
`dest_hostname` and the `g_return_if_fail()` call below, leading to the
code to continue through to `g_object_new()` and use `dest_hostname`
after freeing it.
This introduces no functional changes.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
This should fix a scan-build warning about the final `name_unref()` here
being a use-after-free.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
This should fix a scan-build warning that `resource` is
used-after-freeing in the final `g_resource_unref()` call in
`g_static_resource_fini()`, as `g_resources_unregister_unlocked()` has
already unreffed it.
In reality, each resource has two strong refs on it while active, so the
second unref is correct.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
It is not only shorter than `not meson.is_cross_build() or
meson.has_exe_wrapper()` but also handle the case of cross compiling to
a compatible arch such as building for i386 on an amd64.
This fixes a scan-build warning:
```
../../../../source/glib/gio/glocalfileinfo.c:1661:28: warning: Although the value stored to 'mydirname' is used in the enclosing expression, the value is never actually read from 'mydirname' [deadcode.DeadStores]
mydirname = g_strdup (dirname),
^ ~~~~~~~~~~~~~~~~~~
```
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #1767
`path` was used in building the error message after it had been freed.
Spotted by scan-build.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #1767
This will probably make no functional difference, but will squash two
warnings from scan-build:
```
../../../../source/glib/gio/gsocket.c:503:14: warning: Assigned value is garbage or undefined [core.uninitialized.Assign]
family = address.storage.ss_family;
^ ~~~~~~~~~~~~~~~~~~~~~~~~~
../../../../source/glib/gio/gsocket.c:527:29: warning: Assigned value is garbage or undefined [core.uninitialized.Assign]
socket->priv->family = address.storage.ss_family;
^ ~~~~~~~~~~~~~~~~~~~~~~~~~
```
It seems like a reasonable thing to warn about. Initialising the full
union to zero should avoid any possibility of undefined behaviour like
that.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #1767
This fixes a scan-build warning:
```
../../../../source/glib/gio/tests/gdbus-tests.c:146:3: warning: Value stored to 'watch_id' is never read [deadcode.DeadStores]
watch_id = 0;
^
```
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #1767
Tested using:
```sh
touch ~/foo
gio set ~/foo -t bytestring user::test "\x00\x00"
```
(it doesn’t matter that this fails; the bytestring is still decoded)
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Coverity CID: #1474407
These `memcpy()` calls only happen if `g_inet_address_get_family(group)
== G_SOCKET_FAMILY_IPV4`, so the assertions should never fail.
It’s helpful for understanding the code, and for static analysis, to add
the assertions though.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Coverity CID: #1486858
When I enabled unix socketpair test on win32, I left the existing
g_close(fds[1]), but _g_win32_socketpair() returns native sockets
descriptors that must be closed with closesocket() on win32.
Let GSocket handle the socket pair cleanup.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
When checking that the connection has the expected number of refs, the
test would block on a `GMainContext` iteration for up to 3s before
waking up and failing (if the refcount was still not as expected).
This check was written in the expectation that changing the refcount of
the connection would only happen due to dispatching a source on
`GMainContext` — hence the `GMainContext` would wake up as the refcount
changed.
That’s probably not actually true though. It might be the case that the
connection’s refcount is changed on from the GDBus worker thread, which
would not cause any wakeups on the main thread’s `GMainContext`.
In this case, the `GMainContext` iteration in
`assert_connection_has_one_ref()` would block for the full 3s, and then
wake up and notice the refcount is correct (then the test would
proceed).
That’s fine, apart from the fact that `test_threaded_singleton()` does
this 1000 times. If the slow case is hit on a significant number of
those test runs, the test will take around 3000s to complete, which is
significantly more than meson’s test timeout of 360s. So the test fails
with something like:
```
220/266 glib:gio+slow / gdbus-threading TIMEOUT 360.07 s
--- command ---
G_TEST_SRCDIR='/builds/GNOME/glib/gio/tests' GIO_MODULE_DIR='' G_TEST_BUILDDIR='/builds/GNOME/glib/_build/gio/tests' /builds/GNOME/glib/_build/gio/tests/gdbus-threading
--- stdout ---
\# random seed: R02S83fe8de22db4d4f376e6d179e2bdd601
1..3
\# Start of gdbus tests
ok 1 /gdbus/delivery-in-thread
ok 2 /gdbus/method-calls-in-thread
\# GLib-GIO-DEBUG: refcount of 0x5602de913660 is not right (3 rather than 1) in test_threaded_singleton(), sleeping
\# GLib-GIO-DEBUG: refcount of 0x5602de913660 is not right (3 rather than 1) in test_threaded_singleton(), sleeping
\# GLib-GIO-DEBUG: refcount of 0x5602de913c60 is not right (3 rather than 1) in test_threaded_singleton(), sleeping
\# GLib-GIO-DEBUG: refcount of 0x5602de913c60 is not right (3 rather than 1) in test_threaded_singleton(), sleeping
\# GLib-GIO-DEBUG: refcount of 0x5602de913260 is not right (3 rather than 1) in test_threaded_singleton(), sleeping
\# GLib-GIO-DEBUG: refcount of 0x5602de913260 is not right (3 rather than 1) in test_threaded_singleton(), sleeping
```
From this log, it can be seen that the sleep is happening on a different
`GMainContext` every other time, so the test *is* making progress.
Assuming this is a correct diagnosis (it’s a lot of guessing), this
commit tries to fix the test by adding a wakeup timeout to the
`GMainContext` in `assert_connection_has_one_ref()`, which will wake it
up every 50ms to re-check the exit condition.
This polling approach has been taken because it doesn’t seem feasible to
make sure that every `g_object_ref()`/`g_object_unref()` call on a
`GDBusConnection` causes the main context to wake up.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
This might fix a recent test failure:
https://gitlab.gnome.org/GNOME/glib/-/jobs/1929015. Unfortunately
there’s not much debug information in the logs to go on, and I can’t
reproduce it locally. All I have is:
```
192/272 glib:gio / gdbus-peer-object-manager FAIL 0.43 s (killed by signal 11 SIGSEGV)
--- command ---
GIO_MODULE_DIR='' G_TEST_BUILDDIR='/builds/GNOME/glib/_build/gio/tests' G_TEST_SRCDIR='/builds/GNOME/glib/gio/tests' /builds/GNOME/glib/_build/gio/tests/gdbus-peer-object-manager
--- stdout ---
\# random seed: R02Seee9b7325ecd7c19249a3412397aed9b
1..2
\# Start of gdbus tests
\# Start of peer-object-manager tests
```
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
While the assertion always turned out to be true on Linux, it frequently
caused spurious test failures on FreeBSD.
After some remote debugging, I *think* the cause is as written up in the
comment in the code in this commit. However, I cannot be certain, as the
more debugging messages I added, the harder the failure was to
reproduce; and I don’t have access to a FreeBSD machine.
This fixes failures like:
```
Bail out! GLib-GIO:ERROR:../gio/tests/converter-stream.c:1043:test_converter_pollable: assertion failed (error == NULL): Resource temporarily unavailable (g-io-error-quark, 27)
```
It’s succeeded 1000 times in a row on the FreeBSD CI now; previously
it was failing one time in three:
https://gitlab.gnome.org/GNOME/glib/-/jobs/1936395.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
There’s (deliberately) a bit of race in implementing/handling
`CloseBeforeReturning()` in `gdbus-method-invocation.c`. If the server
closes the D-Bus connection early, the client may exit with `SIGTERM` if
`GDBusConnection:exit-on-close` is set. We don’t want that, as the test
is trying to check that the default handling of a D-Bus method return
after a connection has closed works.
See https://gnome.pages.gitlab.gnome.org/-/glib/-/jobs/1935191/artifacts/_build/meson-logs/testlog.txt
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
G_GNUC_UNUSED does perfectly its job with gcc compiler but the warning
still remains with msvc compiler.
Once the unused variable removed, the finalize vfunc can be removed as
it's doing the same job as the parent function.
We must not open the fd with O_PATH|O_NOFOLLOW,
since the portal rejects that combination. Leaving
out O_NOFOLLOW is fine in this case - we know it
is a directory, we just received EISDIR.
Fixes: #2629
libgamin was last released in 2007 and is dead
[upstream](https://gitlab.gnome.org/Archive/gamin). Distributions may
still ship it (although Fedora no longer does), but we want people to
use inotify on Linux since it’s actively supported.
BSDs use kqueue. Windows uses win32filemonitor.
FAM might still be used on some commercial Unix distributions, but there
are no contributors from those distributions, and certainly no CI for
them to prevent regressions.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2614
It used to exist on Solaris, but GLib’s support for it was mostly
removed in 2015 in commit 21ab660cf8.
Remove the final few references.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
They’re only defined on Unix anyway. `GThreadedResolver` has an entirely
different code path for handling DNS replies on Windows.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
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>
