This will catch buggy implementations of GProxyResolver before they are
able to return bogus results to higher level code. In particular, if
g_proxy_resolver_lookup() returns NULL, it'd better set an error to
explain why.
It doesn't make sense for a proxy resolver to return NULL without an
error on the first call. Whereas a DNS resolver would do this to
indicate that a query completed successfully but found no results, a
proxy resolver should return "direct://" instead. Therefore, if we are
going to return NULL, we ought to have an error as well. Let's make sure
this actually happens by adding some fallback errors just in case
GProxyResolver feeds us weird results.
Additionally, we should not return any errors except
G_IO_ERROR_CANCELLED after the very first iteration. This is an API
contract of GSocketAddressEnumerator. Let's add some checks to ensure
this.
Note that we have inadequate test coverage for GProxyAddressEnumerator.
It's tested here only via GSocketClient. We could do a bit better by
testing it directly as well. For example, I've added tests to see what
happens when GProxyResolver returns both a valid and an invalid URI, but
it's not so interesting here because GSocketClient always uses the valid
result and ignores the error from GProxyAddressEnumerator.
Fixes#2597
This has no practical impact, since it's only a test, and none of the
test code would have hit this bug, but the GTestProxyResolver's check to
see if the URI scheme is simple:// currently only compares the first
four bytes of the string, so it's actually only checking for the "simp"
and would match anything else after that, e.g. "simpleton://". This is
surely not intended.
This was causing intermittent failures on macOS, depending on whether
the tmpdir ended with a `/` or `/some-dir`. `g_strrstr()` is not the
right function to use to extract a basename from a path, for this
reason.
When it failed, the macOS test was failing with:
```
ok 16 /gsubprocess/env
Bail out! GLib-GIO:ERROR:../gio/tests/gsubprocess.c:1507:test_cwd: assertion failed (basename == tmp_lineend_basename): ("/T\n" == "/\n")
```
The test now passes reliably, which means that it can be removed from
the list of expected failures on macOS.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #1392
Creating a `GAppInfo` from a commandline isn’t currently supported on
macOS, but the implementation was incorrectly returning `NULL` without
setting the `GError`.
This was being caught by the new tests in `gio/tests/file.c`.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
On macOS the comparison was failing as one of the paths had a trailing
slash while the other didn’t.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
We used to do get and set atomic operations pair, but these may be
unsafe in some cases as threads may rely on data that is changed in
in between them, however this is not a problem if we do exchange the
pointers.
So just use exchange ops, in this way we can avoid lock/unlock mutex
dances
This makes calls to g_signal_connect_data() and g_signal_connect_object()
with default flags more self-documenting.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Despite the name, the call was still doing blocking operations when
looking for app handlers via GAppInfo. Now it's possible to use fully
async calls.
Together with previous commit, the API is now fully async.
Despite the name, we still used blocking calls to get the default app
for URI, now that we have an async implementation of the API to get the
default implementation for URI scheme, we can remove the blocking calls.
We did not check whether this function worked before, so add a simple
test case for it, providing some test functions to make it possible to
reply the same behavior
In some cases (such as in our CI tests) we may not have any dbus session
set after launching, but we always assumed so.
In case we have not a session bus set, we only have to return early.
In both callbacks of g_file_query_default_handler_async() we were
actually using I/O blocking APIs making it not fully async.
Now that such API is provided, we can use it.
While it's possible to create a directory synchronously via
g_dir_make_tmp(), there's no such API that performs it asynchronously.
So implement it using GFile, using a thread to perform such task.
Avoid re defining cases for GIoErrorEnum when we already handle them
through GFileError, so remove code duplication and just rely on
g_file_error_from_errno() to compute the file error and then use
g_io_error_from_file_error() to get the possible IOError.
In case it's something not handled as GFileError, we can use the same
logic as before.
This is now a safe change to do as we have covered all the supported
cases in tests.
It seems this script has potentially never worked properly under Python
3. It’s supposed to list all the `_get_type()` functions it can find in
the GIO headers, but since the regex string passed to `re.search()` was
not a Python regex, nothing was matching.
Fix that, and do another few small cleanups to the script.
This makes the `defaultvalue` test not skip all the types.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
When running under a strict TAP parser this was previously producing
problematic non-conforming output.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
This is unlikely to be a bug in practice, as the certificate pointed to
by `root` should have a ref held on it as the issuer of another
certificate in the chain.
However, we can’t guarantee that’s how the `GTlsCertificate`
implementation behaves, so keep a temporary ref on `root` until it’s no
longer needed.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Coverity CID: #1489985
Rather than carrying the copylib around inside GLib, which is a pain to
synchronise and affects our code coverage statistics.
This requires updating the CI images to cache the new subproject,
including updating the `cache-subprojects.sh` script to pull in git
submodules.
It also requires adding `gioenumtypes_dep` to be added to the
dependencies list of `libgio`, since it needs to be build before GVDB as
it’s pulled in by the GIO headers which GVDB includes.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2603
The interface was ready for this API but it was not provided.
So implement this, using a thread that calls the sync API for now.
Add tests.
Helps with: GNOME/glib#157
`GSocketClient` chains its internal `GCancellable` objects to ones
provided by the caller in two places using `g_cancellable_connect()`.
However, it never calls `g_cancellable_disconnect()`, instead relying
(incorrectly) on the `GCancellable` provided by the caller being
short-lived.
In the (valid) situation where a caller reuses one `GCancellable` for
multiple socket client calls, or for calls across multiple socket
clients, this will cause the internal `GCancellable` objects from those
`GSocketClient`s to accumulate, with one reference left each (which is
the reference from the `g_cancellable_connect()` closure).
These `GCancellable` instances aren’t technically leaked, as they will
all be freed when the caller’s `GCancellable` is disposed, but they are
no longer useful and there is no bound on the number of them which will
hang around.
For a program doing a lot of socket operations, this still-reachable
memory usage can become significant.
Fix the problem by adding paired `g_cancellable_disconnect()` calls.
It’s not possible to add a unit test as we can’t measure still-reachable
memory growth before the end of a unit test when everything has to be
freed.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2670
Dynamically, these will only ever be used after they’ve been initialised
due to correct checking of `use_udp` throughout the test. However,
that’s a global variable and the static analyser is assuming it might
change value. So help it out by NULL-initialising the variables so they
can never be used uninitialised.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
This is a fallback timeout to abort the test if the expected number of
messages aren’t seen in time. However, when running the test under
valgrind it will take longer and sometimes spuriously trigger the
timeout.
There’s no point in having an abort timeout inside the test: the test
runner (Meson) already provides one for us, which we can adjust with a
multiplier when running under valgrind.
So removes the timeout from within the test. This should fix the
gnotification test under valgrind.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
This re-applies a chunk from commit e63262d49d which was
accidentally lost when upstreaming the commit to xdgmime (as
https://gitlab.freedesktop.org/xdg/xdgmime/-/merge_requests/10).
The upstreamed commit was then re-backported to GLib as a1bfe899ab,
without the missing chunk.
The missing chunk is potentially causing incorrect content type results
for `file://` URIs when used from webkitgtk.
Thanks to Stephen Jung and Michael Catanzaro for investigating.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2639
These have all been added manually, as I’ve finished all the files which
I can automatically detect.
All the license headers in this commit are for LGPL-2.1-or-later, and
all have been double-checked against the license paragraph in the file
header.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #1415
This may have been causing an intermittent failure of the pollable test
on BSD, where updating the readable status of a socket takes a bit
longer than on Linux.
```
GLib-GIO-DEBUG: 16:06:41.235: GSocketClient: Starting application layer connection
GLib-GIO-DEBUG: 16:06:41.235: GSocketClient: Connection successful!
Bail out! GLib-GIO:ERROR:../gio/tests/pollable.c:73:check_source_readability_callback: assertion failed (readable == expected): (0 == 1)
```
I have not debugged the test on BSD, though, so this is only a guess.
See https://gitlab.gnome.org/GNOME/glib/-/jobs/2022087
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
This should make each unit test a bit more self-contained and easier to
verify that they’re independent.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
This test is opportunistic in that it’s not possible to detect whether
the race condition has been hit (other than by hitting a deadlock).
So the only approach we can take for testing is to loop over the code
which has previously been known to cause a deadlock a number of times.
The number of repetitions is chosen from running the test with the
deadlock fix reverted.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #1941
This should prevent unbounded growth of the `event_queue` in the
unlikely case that the `GSource` is removed from its `GMainContext` and
destroyed separately from the `GFileMonitor`.
I’m not sure if that can currently happen, but it could with future
refactoring, so it’s best to address the possibility now while we’re
thinking about this bit of code.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #1941
Taking a reference to the GFileMonitor when handling events may cause
object destruction from th worker thread that calls the function. This
condition happens if the surrounding code drops the otherwise last
reference ot the GFileMonitor. The series of events causes destruction
from an unrelated worker thread and also triggers g_file_monitor_cancel
to be called from g_file_monitor_source_handle_event.
For the inotify backend, this results in a deadlock as cancellation
needs to take a lock that protects data structures from being modified
while events are dispatched.
One alternative to this approach might be to add an RCU (release, copy,
update) approach to the lists contained in the wd_dir_hash and
wd_file_hash hash tables.
Fixes: #1941
An example stack trace of this happening is:
Thread 2 (Thread 0x7fea68b1d640 (LWP 260961) "gmain"):
#0 syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
#1 0x00007fea692215dc in g_mutex_lock_slowpath (mutex=mutex@entry=0x7fea6911e148 <g.inotify_lock_lock>) at ../glib/gthread-posix.c:1493
#2 0x00007fea69222062 in g_mutex_lock (mutex=mutex@entry=0x7fea6911e148 <g.inotify_lock_lock>) at ../glib/gthread-posix.c:1517
#3 0x00007fea6908025a in _ih_sub_cancel (sub=0x1492620) at ../gio/inotify/inotify-helper.c:131
#4 0x00007fea6907f9da in g_inotify_file_monitor_cancel (monitor=0x14a3550) at ../gio/inotify/ginotifyfilemonitor.c:75
#5 0x00007fea68fae959 in g_file_monitor_cancel (monitor=0x14a3550) at ../gio/gfilemonitor.c:241
#6 0x00007fea68fae9dc in g_file_monitor_dispose (object=0x14a3550) at ../gio/gfilemonitor.c:123
#7 0x00007fea69139341 in g_object_unref (_object=<optimized out>) at ../gobject/gobject.c:3636
#8 g_object_unref (_object=0x14a3550) at ../gobject/gobject.c:3553
#9 0x00007fea6907507a in g_file_monitor_source_handle_event (fms=0x14c3560, event_type=<optimized out>, child=0x7fea64001460 "spawned-1", rename_to=rename_to@entry=0x0, other=other@entry=0x0, event_time=<optimized out>) at ../gio/glocalfilemonitor.c:457
#10 0x00007fea6907fe0e in ih_event_callback (event=0x7fea64001420, sub=0x1492620, file_event=<optimized out>) at ../gio/inotify/inotify-helper.c:218
#11 0x00007fea6908075c in ip_event_dispatch (dir_list=dir_list@entry=0x14c14c0, file_list=0x0, event=event@entry=0x7fea64001420) at ../gio/inotify/inotify-path.c:493
#12 0x00007fea6908094e in ip_event_dispatch (event=0x7fea64001420, file_list=<optimized out>, dir_list=0x14c14c0) at ../gio/inotify/inotify-path.c:448
#13 ip_event_callback (event=0x7fea64001420) at ../gio/inotify/inotify-path.c:548
#14 ip_event_callback (event=0x7fea64001420) at ../gio/inotify/inotify-path.c:530
#15 0x00007fea69081391 in ik_source_dispatch (source=0x14a2bf0, func=0x7fea69080890 <ip_event_callback>, user_data=<optimized out>) at ../gio/inotify/inotify-kernel.c:327
#16 0x00007fea691d0824 in g_main_dispatch (context=0x14a2cc0) at ../glib/gmain.c:3417
#17 g_main_context_dispatch (context=0x14a2cc0) at ../glib/gmain.c:4135
#18 0x00007fea691d0b88 in g_main_context_iterate (context=context@entry=0x14a2cc0, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at ../glib/gmain.c:4211
#19 0x00007fea691d0c2f in g_main_context_iteration (context=0x14a2cc0, may_block=may_block@entry=1) at ../glib/gmain.c:4276
#20 0x00007fea691d0c81 in glib_worker_main (data=<optimized out>) at ../glib/gmain.c:6176
#21 0x00007fea691f9c2d in g_thread_proxy (data=0x1487cc0) at ../glib/gthread.c:827
#22 0x00007fea68d93b1a in start_thread (arg=<optimized out>) at pthread_create.c:443
#23 0x00007fea68e18650 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81
This introduces no functional changes but will make refactoring a bit
easier in the following commit.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
The user data parameters in callbacks need to be named user_data to
generate correct closure attributes in the introspection data. This
updates parameters missed in GNOME/glib!2633.
Add SPDX license (but not copyright) headers to all files which follow a
certain pattern in their existing non-machine-readable header comment.
This commit was entirely generated using the command:
```
git ls-files gio/tests/*.c | xargs perl -0777 -pi -e 's/\n \*\n \* This library is free software; you can redistribute it and\/or\n \* modify it under the terms of the GNU Lesser General Public/\n \*\n \* SPDX-License-Identifier: LGPL-2.1-or-later\n \*\n \* This library is free software; you can redistribute it and\/or\n \* modify it under the terms of the GNU Lesser General Public/igs'
```
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #1415
Add SPDX license (but not copyright) headers to all files which follow a
certain pattern in their existing non-machine-readable header comment.
This commit was entirely generated using the command:
```
git ls-files gio/*.[ch] | xargs perl -0777 -pi -e 's/\n \*\n \* This library is free software; you can redistribute it and\/or\n \* modify it under the terms of the GNU Lesser General Public/\n \*\n \* SPDX-License-Identifier: LGPL-2.1-or-later\n \*\n \* This library is free software; you can redistribute it and\/or\n \* modify it under the terms of the GNU Lesser General Public/igs'
```
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #1415
The raw value is escaped according to D-Bus rules. This is probablematic
for Windows backslashed paths. We can use URI unescaping, it seems
that's what gdbusaddress.c is doing too.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
The AF_UNIX API is available under all platforms since 2.71.1, and
credentials functions returns NOT_SUPPORTED error appropriately,
we can thus remove the special-casing for !unix.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
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>
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
Rather than tracking them with a counter. This should close the race in
tracking the finalisation of the tasks by the task worker thread.
There’s no way to synchronise with that thread as it’s internal to
`g_task_run_in_thread()`.
This should hopefully stop the `debugcontroller` test being flaky.
See https://gitlab.gnome.org/GNOME/glib/-/merge_requests/2486#note_1384102
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
We are matching `<parameter>` as well as `<para>`, and we
end up with broken XML in case the (expanded) description
starts with `<parameter>`.
Fixes: #2601
This allows the controller to explicitly be removed from the bus, in a
way that allows the caller to synchronise with it and know that all
other references to the controller should have been dropped (i.e. after
this method returns, there should be no in-flight D-Bus calls still
holding a reference to the object).
This is needed to be able to guarantee finalisation of the controller in
unit tests (and comparable real-world situations).
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #1190
The resources data is generated for both GCC and MSVC toolchains, even
though we know beforehand which toolchain we're going to compile it for.
By dropping the data duplication we make the generated resources file
faster to compile, especially when dealing with large embedded data,
instead of relying on the C pre-processor to walk the whole file and
discard the branch we're not using.
There shouldn’t be any issues here with empty argv arrays since an empty
`Exec=` line is already checked for. Encode that explicitly with an
assertion.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
This won’t really affect anything, but we might as well fix them to not
crash if called with an empty `argv` by someone (ab)using `execve()`.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
While it’s not usual, it is possible for applications to be called with
an empty `argv` by a process (ab)using `execve()`. Modify the
`GApplication` code example to handle that possibility, so that anyone
copying the example isn’t introducing a bug into their program
immediately.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
If `GDebugControllerDBus` remains as the only, or default,
implementation of `GDebugController`, `dup_default()` cannot work.
`GDebugControllerDBus` requires a `GDBusConnection` at construction
time, which the `GIOModule` construction code can’t provide it.
Either we use a default D-Bus connection (but which one? and how would
it be changed by the user later if it was the wrong one?), or delegate
singleton handling of the `GDebugController` to the user.
The latter approach seems more flexible.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #1190
On Windows, dbus is launched by spawning the gdbus.exe executable on
demand from the gio module. When linked dynamically, the executable
path is guessed relatively to the gio DLL path. But when linked
statically, the only reference path available is the current
executable path. In this case, gdbus.exe is not necessarily in the same
folder as the current executable.
This patch solves the issue using the same algorithm as the one used
with process spawning in glib core source code two commits above.
This is intended to provide a uniform interface for controlling whether
the debug output from an application (or service) is emitted, typically
to journald, but actually to wherever the application chooses to output
it.
The main implementation of `GDebugController` is `GDebugControllerDBus`,
which is intended to be used on Linux. Other implementations may be
added in future for other platforms, or larger applications may want to
provide their own implementation which integrates with their ecosystem.
The `GDebugControllerDBus` implementation exposes a D-Bus interface at
`/org/gtk/Debugging` with a method to enable or disable debug
output at runtime.
This could be used by external harnesses, such as GNOME Builder or
systemd, to give a uniform way to get debug output from an application.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #1190
As with the previous commit, this isn’t needed for GLib’s tests to work
correctly, but is probably needed in other projects which might be
tempted to copy and paste the Meson tooling from GLib.
Inspired by https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/4330
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
This isn’t needed to make the tests any better (it doesn’t really affect
them), but is probably needed for anyone who copies this Meson code in
order to add `glib-compile-resources` support to their project. It’s
pretty unlikely that someone would want to compile *and export* a
resource from a shared library.
Inspired by https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/4334
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Credentials are often used to check peer processes details.
With AF_UNIX sockets on Windows, SIO_AF_UNIX_GETPEERPID can
be used to retrive the peer PID.
We will probably introduce more advanced mechanisms later on, though,
but I am not a Windows API expert.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
On !UNIX, return an error for send_fd() & receive_fd().
(the unixfdmessage unit is not compiled on !UNIX)
The header is installed under the common GIO include directory.
Ensure G_TYPE_UNIX_CONNECTION is registered on all platforms.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
The header is now also installed under the common GIO include directory.
Sorry if it breaks any build, you had to use the correct header path.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Move the header under the common GIO include directory.
Sorry if it breaks any build, you had to use the correct header path.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
They are not allowed in the specification, and can lead to infinite
loops when parsing.
That’s a security issue if your application is accepting D-Bus messages
from untrusted peers (perhaps in a peer-to-peer connection). It’s not
exploitable when your application is connected to a bus (such as the
system or session buses), as the bus daemons (dbus-daemon or
dbus-broker) filter out such broken messages and don’t forward them.
Arrays of zero-length elements are disallowed in the D-Bus
specification: https://dbus.freedesktop.org/doc/dbus-specification.html#container-types
oss-fuzz#41428, #41435Fixes: #2557
Glib cannot be built statically on Windows because glib, gobject and gio
modules need to perform specific initialization when DLL are loaded and
cleanup when unloaded. Those initializations and cleanups are performed
using the DllMain function which is not called with static builds.
Issue is known for a while and solutions were already proposed but never
merged (see: https://gitlab.gnome.org/GNOME/glib/-/issues/692). Last
patch is from version 2.36.x and since then the
"constructor/destructor" mechanism has been implemented and used in
other part of the system.
This patch takes back the old idea and updates it to the last version of
glib to allow static compilation on Windows.
WARNING: because DllMain doesn't exist anymore in static compilation
mode, there is no easy way of knowing when a Windows thread finishes.
This patch implements a workaround for glib threads created by calling
g_thread_new(), so all glib threads created through glib API will behave
exactly the same way in static and dynamic compilation modes.
Unfortunately, Windows threads created by using CreateThread() or
_beginthread/ex() will not work with glib TLS functions. If users need
absolutely to use a thread NOT created with glib API under Windows and
in static compilation mode, they should not use glib functions within
their thread or they may encounter memory leaks when the thread finishes.
This should not be an issue as users should use exclusively the glib API
to manipulate threads in order to be cross-platform compatible and this
would be very unlikely and cumbersome that they may mix up Windows native
threads API with glib one.
Closes#692
