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
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
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
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.
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.
As per commit a5390002 we're exiting with error in case fgets failed,
however it could also fail because of EOF (like on ^D), so in such case
we can just return early treating it as a non-error.
Otherwise still exit with error.
Fixes: #2737
* Remove an unneeded field from LaunchUrisData and add annotations
* Rename local GError* variables to local_error
* Use g_set_object
* Fix indentation
...of the application if many URI's are provided. This is important to note
because the GAppLaunchContext signals may be emitted multiple times during
a single launch operation.
We cannot cancel a spawn operation, but sometimes we have to
spawn the target application mutiple times (e.g. in case the
target app only supports one URI in its command-line, but we
were given multiple URI's), in that case continuously check
the cancellation status before attempting any spawn operation
First, there's no reason not to use the new `epoll_create1` system call,
which quickly obsoleted `epoll_create` which has an obsolete and
unused size argument.
But more specifically, it offers `EPOLL_CLOEXEC` which we want
to use for general hygeine - there's no reason to potentially
leak this file descriptor to forked processes.
(GLib itself carefully closes file descriptors when forking child
processes, but it may be linked with other software that doesn't;
notably in my case for example the Rust standard library does not
do this and hence relies more on the application code using
`O_CLOEXEC` and variants)
This is just a drive-by fix; I saw the system call when I was using
`strace` to debug something else in rpm-ostree.
This utility function will be called by both launch_uris and
launch_uris_async, passing a from_task parameter respectively
as NULL and non-NULL. The from_task parameter will be needed
to know whether GAppLaunchContext signals should be emitted
directly (from_task == NULL) or scheduled for emission on the
main thread (from_task != NULL).
All of these warnings indicate programmer error, so critical is most
appropriate here.
Exceptions: deprecation warnings are just warnings. Also, warnings that
are worded with uncertainty can remain warnings rather than criticals.
Using the Application Activation Manager coclass. Its threading model
is marked as 'both', so it can be instantiated in any apartment type
without marshaling.
gio tool has support for deleting attributes of the file. To delete attribute user
should specify type '--type="unset"'. This is not mentioned in help and therefore not
intuitive. By adding '-d' option, we make this process more obvious.
closes#2588
The prefix for GMarkupParseFlags enumeration members is G_MARKUP; this
means that G_MARKUP_PARSE_FLAGS_NONE gets split into
GLib.MarkupParseFlags.PARSE_FLAGS_NONE by the introspection scanner.
The `/*< nick=none >*/` trigraph attribute is a glib-mkenum thing, and
does not affect the introspection scanner; it would also only affect the
GEnumValue nickname, which is not used by language bindings to resolve
the name of the enumeration member. Plus, GMarkupParseFlags does not
have a corresponding GType anyway.
The prefix is G_TLS_CERTIFICATE, not G_TLS_CERTIFICATE_FLAGS. Having
G_TLS_CERTIFICATE_FLAGS_NONE leads to a FLAGS_NONE nick in the GType,
and a FLAGS_NONE member name in the introspection data.
Enumeration members should either have the name of the type as their
prefix, or they should all have the same prefix.
The "default flags" enumeration member for GApplicationFlags is
unfortunately named G_APPLICATION_FLAGS_NONE, while every other member
of the same type has a G_APPLICATION prefix. The result is that the nick
name of the enumeration member is "flags-none", and that language
bindings will have to use something like
Gio.ApplicationFlags.FLAGS_NONE.
To fix this API wart, we can deprecate the FLAGS_NONE member, and add a
new DEFAULT_FLAGS.
If stdout is the Journal but stderr is not, then we probably only want
to redirect stdout, or vice versa.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This prevents a launched process's output from being mixed up with the
output of the parent process, which can lead to the wrong program being
blamed for warning messages.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This is an internal helper executable, which users shouldn't invoke
directly (see glib#1633).
When building for a single-architecture distribution, we can install
it as ${libexecdir}/gio-launch-desktop.
When building for a multiarch distribution, installing it into an
architecture-specific location and packaging it alongside the GLib
library avoids the problem discussed in glib#1633 where it would either
cause a circular dependency between the GLib library and a common
cross-architecture package (libglib2.0-bin in Debian), or require a
separate package just to contain gio-launch-desktop, or cause different
architectures' copies to overwrite each other.
Signed-off-by: Simon McVittie <smcv@collabora.com>
gio-launch-desktop was removed before checking GIO for potentially
unsafe environment variable references, so reverting its removal brought
this one back. If a setuid program is using GAppInfo then something is
probably already horribly wrong, but let's be careful anyway.
Signed-off-by: Simon McVittie <smcv@collabora.com>
A shell one-liner was enough to set GIO_LAUNCHED_DESKTOP_FILE_PID,
but ideally we also want to do the equivalent of sd_journal_stream_fd()
to set up its standard output and standard error streams.
Ideally we would call sd_journal_stream_fd() in a process that will
exec the real program, otherwise it will report the wrong process ID
in the Journal, but we can't easily do that in a forked child when
using posix_spawn() for subprocesses.
This reverts commit 2b533ca99a.
Signed-off-by: Simon McVittie <smcv@collabora.com>
The dominant implementations of the well-known session and system
message buses are the reference implementation from the dbus project
(dbus-daemon) and the sd-bus-based reimplementation dbus-broker, both
of which have correct implementations for EXTERNAL authentication with
an unspecified authorization identity.
This makes it reasonably safe to assume that the well-known message
buses can cope with the unspecified authorization identity, even if we
cannot make the same assumption for custom servers such as the ones
used in ibus and gvfs (which might have been started with an older
GLib version before upgrading GLib in-place).
Signed-off-by: Simon McVittie <smcv@collabora.com>
When using a GDBus client in a non-trivial user namespace, the result of
geteuid() can differ from the uid in the namespace where the server is
running. This would result in connection attempts being rejected, because
the identity that the client claims to have does not match the identity
that the server derives from its credentials.
RFC 4422 allows us to send an empty authorization identity, which means we
want to authenticate as whatever identity the server can derive from our
out-of-band credentials. In particular, this resolves the authentication
failure when crossing between different Linux user namespaces.
Because D-Bus does not have a way to represent an empty initial response
as distinct from the absence of an initial response, we cannot use the
initial-response optimization (RFC 4422 §4.3.a) in this case, and must
fall back to waiting for the server to send a challenge.
Unfortunately, GDBus versions older than glib!2826 did not implement
the server side of this protocol correctly, and would respond to the
missing initial response in a way that breaks the SASL state machine
(expecting a response without sending a challenge), causing client and
server to deadlock with each waiting for the other to respond. Until
fixed versions of GDBus are widespread, we can't rely on having a server
that can cope with this, so gate it behind a flag, which can be set for
connections that are known to cross non-trivial namespace boundaries.
Originally inspired by
<1ed4723d38>,
and based on earlier work by Giuseppe Scrivano (in which the
cross-namespace behaviour was unconditional, rather than gated by a
flag).
Co-authored-by: Giuseppe Scrivano <giuseppe@scrivano.org>
Signed-off-by: Simon McVittie <smcv@collabora.com>
In Debian-style multiarch (libdir = lib/x86_64-linux-gnu or similar),
Red-Hat-style multilib (libdir = lib64 or lib) and Arch-style multilib
(libdir = lib or lib32), we have to run a separate version of
gio-querymodules to discover 32- or 64-bit modules on x86. Installing
modules in the directory used for each word size needs to trigger
recompilation of the correct modules list.
Debian, Fedora and Arch currently all have patches to facilitate this:
Debian moves gio-querymodules into ${libdir}/glib-2.0 and provides a
compat symlink in ${bindir}, while Fedora and Arch rename one or both
of the gio-querymodules executables to give it a -32 or -64 suffix.
We can avoid the need for these patches by making this a build option.
Doing this upstream has the advantage that the pkg-config metadata for
each architecture points to the correct executable and is in sync with
reality.
I'm using Debian's installation scheme with a separate directory here,
because the word-size suffix used in Fedora and Arch only works for the
common case of 32- and 64-bit multilib, and does not cover scenarios
where there can be more than one ABI with the same word size, such as
multiarch cross-compilation or alternative ABIs like x32.
Now that we have this infrastructure, it's also convenient to use it for
glib-compile-schemas. This works with /usr/share, so it only needs to
be run for one architecture (typically the system's primary
architecture), but using /usr/bin/glib-compile-schemas for the trigger
would result in either primary and secondary architectures trying to
overwrite each other's /usr/bin/glib-compile-schemas binaries, or a
circular dependency (the GLib library would have to depend on a
common package that contains glib-compile-schemas, but
glib-compile-schemas depends on the GLib library). Installing a
glib-compile-schemas binary in an architecture-specific location
alongside each GLib library bypasses this problem.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Instead of using a GDBusConnection, this does the handshake at a lower
level using specific strings in the SASL handshake, to verify that we
will interoperate with various clients including sd-bus, libdbus and
older versions of GDBus.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This is an interoperability fix. The reference implementation of D-Bus
treats "DATA\r\n" as equivalent to "DATA \r\n", but sd-bus does not,
and only accepts the former.
Signed-off-by: Simon McVittie <smcv@collabora.com>
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>
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>
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>
This attribute will produce "deprecation" warnings when using it in
code that does not want dependencies on newer GLib versions.
Signed-off-by: Simon McVittie <smcv@collabora.com>
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.
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>
The test was flacky because we were only relying on the presence of a
file, while the callback could have not been called yet, while ensure
for both assumptions to be true before stop iterating the loop.
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
These headers have all been written manually, by looking through the git
log for each file and noting the copyright of each significant
contribution.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #1415
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
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
