We don't need a cpp toolchain for building glib so lets just
automatically disable tests requiring one when not available.
Signed-off-by: James Hilliard <james.hilliard1@gmail.com>
(cherry-picked from commit d0b9ebbaacb5f69aaaad30829e04cd3a88f084cb)
Add missing call to _g_io_modules_ensure_extension_points_registered() to
GRegistryBackend, GNullSettingsBackend, and GNextstepSettingsBackend
(cherry-picked from commit 924da751c2d3ed4636223343ebaa7364b97f8f93)
Using GMemorySettingsBackend before any other GSettingsBackend would
cause the following error: "Tried to implement non-registered extension
point gsettings-backend". This is due to a missing call to
_g_io_modules_ensure_extension_points_registered() in the GMemorySettingsBackend
type definition which registers the gsettings-backend extension point.
(cherry-picked from commit 04255e45654bd49f1974a79baeafb33d228f6f71)
RFC 4422 appendix A defines the empty authorization identity to mean
the identity that the server associated with its authentication
credentials. In this case, this means whatever uid is in the
GCredentials object.
In particular, this means that clients in a different Linux user
namespace can authenticate against our server and will be authorized
as the version of their uid that is visible in the server's namespace,
even if the corresponding numeric uid returned by geteuid() in the
client's namespace was different. systemd's sd-bus has relied on this
since commit
1ed4723d38.
[Originally part of a larger commit; commit message added by smcv]
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry-picked from commit b51e3ab09e39c590c65a7be6228ecfa48a6189f6)
Sending an "initial response" along with the AUTH command is meant
to be an optional optimization, and clients are allowed to omit it.
We must reply with our initial challenge, which in the case of EXTERNAL
is an empty string: the client responds to that with the authorization
identity.
If we do not reply to the AUTH command, then the client will wait
forever for our reply, while we wait forever for the reply that we
expect the client to send, resulting in deadlock.
D-Bus does not have a way to distinguish between an empty initial
response and the absence of an initial response, so clients that want
to use an empty authorization identity, such as systed's sd-bus,
cannot use the initial-response optimization and will fail to connect
to a GDBusServer that does not have this change.
[Originally part of a larger commit; commit message added by smcv.]
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry-picked from commit a7d2e727eefcf883bb463ad559f5632e8e448757)
This is an interoperability fix. If the line is exactly "DATA\r\n",
the reference implementation of D-Bus treats this as equivalent to
"DATA \r\n", meaning the data block consists of zero hex-encoded bytes.
In practice, D-Bus clients send empty data blocks as "DATA\r\n", and
in fact sd-bus only accepts that, rejecting "DATA \r\n".
[Originally part of a larger commit; commit message added by smcv]
Signed-off-by: Giuseppe Scrivano <giuseppe@scrivano.org>
Co-authored-by: Simon McVittie <smcv@collabora.com>
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry-picked from commit 764f071909df70622e79ee71323973c18c055c8c)
The search_total_results address is always going to be non-zero, so the
check will always evaluate to true, and GCC is kind enough to point this
out to us.
The appropriate fix is checking if the size of the search results array
is larger than zero, and if so, copy them into the total results array.
(cherry-picked from commit e08c954693fdcfceda2de59cca93a76125f4fca6)
While `gio_xdgmime` is unlocked, the data which `type` points to in the
xdgmime cache might get invalidated, leaving `type` as a dangling
pointer. That would not bode well for the `g_strdup (type)` call to
insert a new entry into the `type_comment_cache` once `gio_xdgmime` is
re-acquired.
This was spotted using static analysis, and the symptoms have not
knowingly been seen in the wild.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Coverity CID: #1474702
(cherry-picked from commit 45d4c525)
It's a busy text file, but we don't care much about specifics so we
can just return the generic busy error.
(cherry-picked from commit 6bc6b7ef3012487966a99a5db06d27000205ab38)
The returned `SocketAddress` is going to be NULL when the stream of
socket addresses is finished
(cherry-picked from commit ac3fc84ff41ad1fbcad765d170f5d741813dc84e)
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
(cherry-picked from commit 2c75c392eb76a12c3fd18b63508b1f971a3afecd)
The `(transfer none)` behaviour for `parameter_type` and `state_type`
parameters is implicit with the `const` attribute, but was incorrectly
determined to be `(transfer full)` in the GIR.
Add explicit `(transfer none)` annotations for these two parameters.
(cherry-picked from commit 1eb1a47a50f31b2cea71cf8c94c8989727abb98c)
On our GDBus call callback wrapper we were completing the gdbus call but
ignoring the returned value, that was always leaked.
Fix this.
Helps with: https://gitlab.gnome.org/GNOME/glib/-/issues/333
(cherry-picked from commit 221f22b6e18fdd306e676e28a79afd3697bddd03)
When launching URIs via dbus we may ignore the callback if one was not
provided, however in such case we were also leaking the return value for
the gdbus call.
Unref it properly.
Helps with: https://gitlab.gnome.org/GNOME/glib/-/issues/333
(cherry-picked from commit 026a69905eec18e9ea0486ea351496e461c8681e)
We were testing the case in which we were opening an actual file, and so
potentially using a fd-list, however we were missing the case in which a file
was not existent.
And in such case we are incidentally hitting a leak now.
(cherry-picked from commit 511627b7356af527c85c049e2020a36694d7de54)
When called with an empty URI list (or only inaccessible files),
g_document_portal_add_documents would not call g_variant_builder_end,
leaking the memory allocated by the variant builder.
Closes: https://gitlab.gnome.org/GNOME/glib/-/issues/2733
(cherry-picked from commit 27203e48c91ab8b55033dcf1773cb60c0aaed3fa)
Fix a regression from commit abddb42d14, where it could pass `NULL` to
`g_task_get_cancellable()`, triggering a critical warning. This could
happen because the lifetime of `data->task` is not as long as the
lifetime of the `ConnectionAttempt`, but the code assumed it was.
Fix the problem by keeping a strong ref to that `GCancellable` around
until the `ConnectionAttempt` is finished being destroyed.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2687
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.
(Backport to 2.72: Dropped new translatable strings in error messages to
avoid additional translation work on a stable branch. The error messages
are unlikely to be seen by users.)
Fixes#2597
`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
This re-applies a chunk from commit e63262d49d40a36060 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 a1bfe899abe,
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
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
`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
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
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>
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>
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
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>
