It needs to be in a separate page because there isn’t actually a
`GFileAttribute` type.
Signed-off-by: Philip Withnall <philip@tecnocode.co.uk>
Helps: #3037
Move it to the struct docs, although again this is a little suspect
because there is actually no `GDBusAddress` struct/type.
Signed-off-by: Philip Withnall <philip@tecnocode.co.uk>
Helps: #3037
This might not work, as `GContentType` isn’t actually a defined type
(content types are just strings). It would be a bit weird to create a
separate page for content types, though, as the functions handling them
are very method-like and feel like they should be grouped together like
methods of a class.
Signed-off-by: Philip Withnall <philip@tecnocode.co.uk>
Helps: #3037
Currently, the introspection data for GLib and its sub-libraries is
generated by gobject-introspection, to avoid the cyclic dependency
between the two projects.
Since gobject-introspection is generally available on installed systems,
we can check for its presence, and generate the introspection data
directly from GLib.
This does introduce a cyclic dependency, which is why it's possible to
build GLib without introspection, then build gobject-introspection, and
finally rebuild GLib.
By having introspection data available during the GLib build, we can do
things like generating documentation; validating newly added API; and
close the loop between adding new API and it becoming available to non-C
consumers of the C ABI (i.e. language bindings).
If `update-desktop-database` or `update-mime-database` are not
installed, there are a few `GAppInfo` methods for modifying file
associations which will print a `g_warning()` when called. Something
like:
```
GLib-GIO-FATAL-WARNING: Failed to execute child process ‘update-desktop-database’ (No such file or directory)
```
(Example: https://gitlab.gnome.org/zamaudio/glib/-/jobs/3190053)
This will cause the appinfo/associations test to fail, as warnings are
fatal.
If that’s going to happen, skip the test. We can’t hard-depend on these
tools as they are external to GLib and only needed for a few operations.
Instead we have a soft runtime dependency on them; that should be
reflected in the tests.
Signed-off-by: Philip Withnall <philip@tecnocode.co.uk>
Helps: #3148
Commit f6c40b1d fixed libelf detection on FreeBSD (where the library has
no pkg-config file and needs to be found via `find_library()`), but
broke `-Dlibelf=disabled` on Linux, as `get_option('libelf')` was no
longer checked.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #3120
Add a default modification timestamp flag to g_file_copy so that it
doesn't copy the modification time from the source file as it does by
default. Similarly to G_FILE_COPY_TARGET_DEFAULT_PERMS, this flag
overrides the G_FILE_COPY_ALL_METADATA flag.
Fixes: https://gitlab.gnome.org/GNOME/glib/-/issues/3140
There are some flavors of MIPS ABIs, such like r6 vs legacy,
nan2008 vs nan1985 etc.
The `cc -r` may not produce the correct elf binaries.
So let's skip this test for MIPS.
Many toolchain did not change the definition of NULL to avoid introducing
breaking changes in existing codebases. For example, on Windows NULL is
0 (int) regardless of the C++ standard in use.
Fixes the following warnings on CLang when compiling for Windows:
../glib/glib/tests/cxx.cpp:539:34: warning: missing sentinel in function call [-Wsentinel]
g_test_init (&argc, &argv, NULL);
^
, nullptr
../glib/glib/gtestutils.h:298:9: note: function has been explicitly marked sentinel here
void g_test_init (int *argc,
^
../glib/gio/tests/cxx.cpp:62:34: warning: missing sentinel in function call [-Wsentinel]
g_test_init (&argc, &argv, NULL);
^
, nullptr
../glib/glib/gtestutils.h:298:9: note: function has been explicitly marked sentinel here
void g_test_init (int *argc,
^
Fixes the following warnings on CLang:
../glib/gio/gregistrysettingsbackend.c:1503:32: warning: implicit truncation from 'int' to a one-bit wide bit-field changes value from 1 to -1 [-Wsingle-bit-bitfield-constant-conversion]
child_item->readable = TRUE;
^ ~~~~
../glib/gio/gregistrysettingsbackend.c:1567:28: warning: implicit truncation from 'int' to a one-bit wide bit-field changes value from 1 to -1 [-Wsingle-bit-bitfield-constant-conversion]
child_item->readable = TRUE;
^ ~~~~
The C standard does not specify whether the underlying type of an enum
is signed or unsigned, and until C23 there was no way to control this
explicitly. GCC appears to make enums unsigned unless there is a
negative value among cases of the enum, in which case it becomes signed.
MSCV appears to make enums signed by default.
A bitfield of an enum type (which is not specificied in the C standard
either) behaves as if it was an instance of a numeric type with a
reduced value range. Specifically, a 'signed int val : 2;' bitfield will
have the possible values of -2, -1, 0, and 1, with the usual wraparound
behavior for the values that don't fit (although this too is
implementation-defined).
This causes the following issue, if we have:
typedef enum
{
G_ZERO,
G_ONE,
G_TWO
} GFoo;
struct _GBar
{
GFoo foo : 2;
};
and then assign bar.foo = G_TWO and read it back, it will have the
expected value of 2 (aka G_TWO) on GCC, but a value of -2 (not matching
any of the enum variants) on MSVC.
There does not seem to be any way to influence signedness of an enum
prior to C23, nor is there a 'unsigned GFoo foo : 2;' syntax. The only
remaining options seems to be never using enums in bitfields, which is
what this change implements.
This corresponds to https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/6467
in GTK.
Signed-off-by: Sergey Bugaev <bugaevc@gmail.com>
This triggered a warning from the CHERI compiler since the struct contains
a `void *` but `__attribute__((aligned(8))` reduced alignment to less than
the `void *` alignment (which is 16 for Arm Morello).
Helps: https://gitlab.gnome.org/GNOME/glib/-/issues/2842
This should not result in any functional changes, but will eventually
allow glib to be functional on CHERI-enabled systems such as Morello.
Helps: https://gitlab.gnome.org/GNOME/glib/-/issues/2842
It’s not actually needed on any platform, and causes compilation
problems on platforms where it’s not available.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #3111
The Comment field provides a user-visible description of the app,
which usually contains generic words ("and", "or", "not", "is", ...)
that add noise when used for search.
It made some sense to match against the field as a fallback for
Keywords, before that key was well established. However that key
has been around for years now, so hopefully every app where additional
terms are helpful uses it by now.
With that, the downside of added noise outweighs the benefit, so
it's time to stop matching on comments.
When setting the file time using utimensat, don't ignore
microseconds for access/modify times. By doing that, they're preserved
when using g_file_info_set_modification_date_time and then setting the file's
attributes from it.
Fixes#3116
Commit 9e2ad88455 improved app search results by allowing to differentiate
their match_type: prefix match or substring match; while giving more priority
to prefix matches over substring matches, but only when they are in the same
match_category[1].
This was a step forward but, as outlined in #3082, still not enough to get
most relevant results first to the user, because apparently (and for the
specific case of desktop app searching) a prefix match in a lower category
is more relevant to the user than a substring match in a higher category.
So that's what this commit implements, i.e. it makes sure prefix matches
are still preferred over substring matches but this time not only when
in the same category but also across different categories.
[1] Match category is the Desktop file key where the match happened.
They are shown below from top to lesser priority.
DESKTOP_KEY_Name
DESKTOP_KEY_Exec
DESKTOP_KEY_Keywords
DESKTOP_KEY_GenericName
DESKTOP_KEY_X_GNOME_FullName
DESKTOP_KEY_Comment
Fixes#3082
· Add a usage output that is printed when called with no argument
or with '--help' argument. This is helpful as it avoids having
to read the source code to know how to run the different options.
· Adds new '--should-show-only' option to 'search' command, to
better mimick the gnome-shell app search, by not returning
apps with NoDisplay=true.
Example for running a desktop app search with the new option from
inside the GLib build dir:
$ gio/tests/apps search --should-show-only settings
Make sure to fail consistently in case people created a GPropertyAction
with g_object_new() without passing a property name.
Bindings that construct objects with g_object_new() have no idea if a
property is mandatory.
See: #3130
This avoids a critical warning from trying to disconnect a signal
handler from a `NULL` object if `paction->object` is `NULL` for whatever
reason (see: the following commit).
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #3130
The `GTK_USE_PORTAL` environment variable has started to be misused by
users, which is causing deployment issues (such as portal services
themselves ending up being forced to use portals, which is never going
to work).
Try and sidestep users’ broken configurations by renaming the
environment variable, and also separating it from the old GTK
environment variable, since the GLib one affects a lot more processes.
This environment variable is meant to be used for
debugging and development, and never in production.
GTK already renamed their environment variable in
https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/4829, so keeping the
`GTK_USE_PORTAL` name in GLib doesn’t make sense anyway.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #3107
I had thought that because `g_source_destroy()` was called for the two
sources (cancel and timeout) in the `GTask` finalize function for a
threaded resolver operation, that it would be fine to use a plain
pointer in the source callbacks to point to the `GTask`.
That turns out to not be true: because the source callbacks are executed
in the GLib worker thread, and the `GTask` can be finalized in another
thread, it’s possible for a source callback (e.g. `cancelled_cb()`) to
be scheduled in the worker thread, then for the `GTask` to be finalized,
and then the source callback to continue execution and find itself
doing a use-after-free.
Fix that by using a weak ref to the `GTask` in the source callbacks,
rather than a plain pointer.
Signed-off-by: Philip Withnall <philip@tecnocode.co.uk>
Fixes: #3105
The fields are fully validated in `validate_headers()` in
`gdbusmessage.c` now, so the connection code should be able to rely on
the required ones being non-`NULL`.
Signed-off-by: Philip Withnall <philip@tecnocode.co.uk>
Helps: #3061
`object_path` and `path` were doing exactly the same thing here.
This introduces no functional changes.
Signed-off-by: Philip Withnall <philip@tecnocode.co.uk>
We already validated that the required headers for each type of D-Bus
message were present. However, we didn’t validate that they contained a
variant of the right type. This could lead to functions like
`g_dbus_message_get_path()` returning `NULL` unexpectedly.
This failure could only be hit when using GDBus in peer-to-peer mode, or
with a D-Bus server which didn’t validate the headers itself. The
reference D-Bus server does validate the headers, and doesn’t forward
invalid messages to clients.
Signed-off-by: Philip Withnall <philip@tecnocode.co.uk>
Fixes: #3061
Add test cases that result in lookup of the port via
getservbyname().
As the result depends on "/etc/services", it's not reliably the same on
every system. It requires a workaround.
Commit cf55c31170 added a new test which
uses `ptrace()` to check some `GSubprocess` behaviour. FreeBSD uses
different symbol names for ptrace symbols, and we haven’t tested whether
the test works (and reproduces the failure) on FreeBSD, so skip the test
for now.
Signed-off-by: Philip Withnall <philip@tecnocode.co.uk>
The tooling won’t pick them up unless they’re directly above the gettext
calls.
Spotted by Piotr Drąg in
ec03755355 (note_1808152).
Signed-off-by: Philip Withnall <philip@tecnocode.co.uk>
The test case will fail with the
g_assert_false (g_subprocess_get_successful (proc));
assert failing. Without the fix, it'll hit sometimes, but rather
unreliably. When running `meson test --repeat 100`, it'll reproduce
anywhere between the first or much later, but mostly before the 20th
iteration on my system.
Helps: #3071
It's not safe to use setlocale() to mutate the locale in a threaded
program. Lots of other tests still do this, and I'm not putting in the
effort to fix them comprehensively in the absense of actual failures on
CI, but I figured it'd be good to fix the tests that I was touching.
This definitely does not do anything on Linux. I bet it's not needed on
other platforms, either. It's unsafe and may crash; there is no safe way
to mutate the environment in threaded programs.
This is a copy of the existing test_l10n, modified to use LC_TIME
instead of LC_MESSAGES. It's not safe as each call to g_setenv() or
setlocale() could cause the test to crash; there is no safe way to
change a threaded process's environment, and a threaded process's locale
can only be safely changed using uselocale(), not with setlocale().
The calls to g_setenv() are definitely not needed on Linux. I wonder
whether removing these will break the test on other platforms?
The calls to setlocale() should be replaced by a dance of
uselocale() -> duplocale() -> newlocale() -> uselocale() on Linux. But
this is not portable and this is a cross-platform test. We would have to
make the test platform-specific to do this. macOS and at least FreeBSD
provide these functions via xlocale.h, but this isn't portable.
It's supposed to be possible to translate settings values using LC_TIME
rather than LC_MESSAGES to determine which translation to use, but
Sebastian Keller noticed that it's not working properly. I've
implemented his proposed solution, which is to actually temporarily
change LC_MESSAGES to match LC_TIME for just as long as necessary to
force gettext to use the desired message catalog.
Fixes#2575
Fix typo in gio/gappinfo (duplicated word)
Fix typo in gio/gtlsdatabase.c (duplicated word)
Fix typo in gio/gapplication.c (duplicated word, previous words rearranged to improve readability)
Fix typo in glib/tests/gvariant.c (duplicated word)
Fix typo in glib/win_iconv.c (duplicated word)
Fix typo in gio/gschema.dtd (meaning, missing letter)
Fix typo in gio/gdbusintrospection.c (duplicated word)
Fix typo in gio/gdbusintrospection.c (duplicated word).
I made the kqueue failure 100% reliable with `samu -j1` on FreeBSD,
and therefore confirmed this fixes that problem. Issue #2929 is
an identical failure on win32, so I assume this fixes that, too,
but I haven't confirmed.
Fixes: #2929
Following Emmanuele's instructions for use of introspection annotations:
https://www.bassi.io/articles/2023/02/20/bindable-api-2023/
I have audited all uses of the (closure) annotation in glib and
determined that only a handful are correct. This commit changes almost
all of our use of (closure) annotations to conform to Emmanuele's rules.
The test was passing fine when `bindir` was equal to `multiarch_bindir`,
but not when they differ.
For example, on a Debian system, `gio-querymodules` is installed to
`/usr/lib/x86_64-linux-gnu/glib-2.0/gio-querymodules` rather than
`/usr/bin/gio-querymodules` as it is on (say) Fedora.
This was causing the pkg-config tests to fail on Debian.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #3045
This reverts commit 004f48f4fc.
Per the discussion on #3356, this change was prompted by a
misunderstanding of ldflags/link_args, and it resulted in various other
packages using glib no longer getting symbols exported. This commit
restores the glib 2.76 behaviour.
Avoid generating more code than needed, so other than continuing using
the generic glib marshallers when possible, define once the custom ones
we need for each file we generate.
The marshallers are then re-used across all the interfaces defined
without duplicating the code size.
This is the same we're doing in code generated by glib-genmarshaller and
what gmarshal does internally.
Since the generated gdbus C code can be considered private too, this is
safe to do, and will allow faster access to GValue objects.
Get rid completely of the usage of the generic marshaller in gdbus
generated code, using instead specific marshallers.
Code is not yet optimized fully since we may still have duplicated
functions to be generated.
Closes: https://gitlab.gnome.org/GNOME/glib/-/issues/3028
We relied on g_cclosure_marshal_generic() to easily generate signal
marshallers, but this relies on inspecting each parameter type with ffi
and this implies a performance hit, other than breaking the stack-frame
unwinder used by Linux perf and so by sysprof.
Given that we know the types we work on, it's easy enough to generate
the marshallers ourself.
Helps with: https://gitlab.gnome.org/GNOME/glib/-/issues/3028
For some reason, `time_t` is defined as being 32 bits wide on that
platform, which causes truncation of the timestamps from `struct stat`.
Avoid that problem by consistently using a 64-bit return value from the
`struct stat` accessors.
Helps: #3039
We were using emit_by_name which implies looking up for the signal name,
while the generated code can easily remember the signal ID and use it
instead, allowing direct access to the signal emission.
`_g_stat_has_field (statbuf, G_LOCAL_FILE_STAT_FIELD_ATIME)` will always
return `TRUE` on Windows (since it uses a basic `struct stat`), so the
platform-inspecific code is equivalent to the Windows-specific code.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
`GLocalFileStat` is a platform-specific abstraction around `struct stat`
or `struct statx`. If `struct statx` is available, it will use that by
preference as it has more features.
`glocalfileinfo.c` was, in some places, incorrectly accessing the fields
of `GLocalFileStat` directly rather than through its `_g_stat_*()`
getters. While it correctly accounted for the platform-specific
differences between `st_mtimensec` and `st_mtim.tv_nsec`, it hadn’t been
updated to deal with `stx_mtime`.
On Android, `st_mtimensec` is defined as a fallback for
`st_mtim.tv_nsec` (even though it doesn’t need to be). This caused GLib
to take the `st_mtimensec` code path rather than the `stx_mtime` code
path, and hence try to dereference `st_mtim` in a `struct statx`.
Fix that by correctly using the `_g_stat_*()` getters consistently.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #3039
glib-compile-resources --dependency-file= currently generates a depfile
with rules that look like this:
foo.xml: resource1 resource2
This means that if any of the files listed in the GResource manifest
foo.xml change, rebuild foo.xml because foo.xml depends on those files.
This is not useful because the XML manifest is not expected to be a
generated dependency and even if it was, changes to the listed files
would not imply any need to regenerate the manifest. What we really do
need to regenerate is the C source file that is generated by
glib-compile-resources after processing the XML manifest and all the
resource files. That is, the rule should look like this:
foo.c: foo.xml resource1 resource2
as suggested by Hans Ulrich Niedermann in the issue report.
Fixes#2829
Currently we require explicitly specifying the port when configuring a
proxy server, which is seriously weird. I take the fact that nobody
reported a bug until 2022 to indicate that almost nobody is using
proxies. Whatever. Let's assume that if no port is provided, the default
port for the protocol should be used instead.
For example, you can now specify in GNOME settings that your proxy server
is https://example.com and it will work. Previously, you had to write
https://example.com:443. Yuck!
This was originally reported as GProxyResolver bug, but nothing is
actually wrong there. It's actually GProxyAddressEnumerator that gets
tripped up by URLs returned by GProxyResolver without a default port.
This breaks GSocketClient.
Fixing this requires exposing GUri's _default_scheme_port() function to
GIO. I considered copy/pasting it since it's not very much code, but I
figure the private call mechanism is probably not too expensive, and I
don't like code duplication.
Fixes#2832
On some platforms, pointer-sized reads are not necessarily atomic, so we
always need to use the correct atomic access primitives.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
When the gnome test runner executes the tests, the test appear to execute in disk
order. This means it sometimes works and sometimes we see breakage in portal-support-snap
and portal-support-snap-classic.
The issue is that some tests create config files but some don't. If they run
in the wrong order, tests see config files they shouldn't and break.
Fix this by deleting the files after each test run, properly cleaning up after
themselves. The cleanup code is based upon gtestutils.c:rm_rf().
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Since we have a convenience method to add actions let's allow to remove
them just as easily. This makes resource cleanup as simple as initially
adding the entries.
Makes the tests compile using clang with meson directly under
termux on android, this build environment does not approve of
overloading libc symbols.
Fixes: #3008
foo
This is a workaround for build conditions one ends up with under termux,
where the defined __ANDROID_API__ level is lower than what is provided
by gcc installed for it, the libc .so nevertheless contains these symbols
thus enabling the codepaths. This definition is only in use when meson
detected the presence of this symbol in the libc.
Fixes#3008
foo
In the typical `while (g_file_enumerator_next_file ())` patterns,
there is nothing much checking whether the operation was cancelled
on the GIO side. Unless the user checks for the case, this means
local enumerators always run to completion even if cancelled.
Fix this by checking the cancellable state explicitly for local
enumerators, so there are oportunities for bailing out early if
the enumerator is going through a very large directory.
Note that the prepare callback only has one caller, which pre-initializes
the timeout argument to -1. That may be an implementation detail and not
publicly promised, but it wouldn't make sense to do it any other way in
the caller.
Also, note that g_unix_signal_watch_prepare() and the UNIX branch of
g_child_watch_prepare() already relied on that.
When `copy_file_range()` support was added, I used the definition of
`copy_file_range()` from Linux, which uses `loff_t` to abstract the
different `off*_t` types.
`loff_t` doesn’t exist on FreeBSD, so this doesn’t compile, and was
caught in subsequent asynchronous CI.
Define `loff_t` with a fallback value if it’s not defined, which should
fix this and other uses of `loff_t` in `gfile.c` (for example, if
FreeBSD ever starts declaring `splice()`).
Fixes this CI failure: https://gitlab.gnome.org/GNOME/glib/-/jobs/2812302
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
GTK lost it's '+' suffix back in 2019, according to
<https://mail.gnome.org/archives/gtk-devel-list/2019-February/msg00000.html>
This commit can be re-generated with:
git grep -l GTK+ \
| grep -v -e ^NEWS -e ^glib/tests/collate.c \
| xargs sed -i 's/GTK+/GTK/g'
Most of the changes are in comments and documentation.
While it can’t be used in all situations, it is a little bit faster than
`splice()` in some situations, basically if the file system supports
copy on write. In other situations it’s no slower than `splice()`.
See `man copy_file_range` for the situations where it doesn’t work. In
all of these situations, it will return an error, and the GLib code will
fall through and try the existing `splice()` copy code instead.
From my testing of `time gio copy A B` with a 9GB file, the `splice()`
code path takes 22s, and the `copy_file_range()` code path takes 20s.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2863
The start of the `g_file_copy()` implementation stats the source file to
find all the attributes to copy onto the destination file, so it makes
sense to get it to store the source file size at the same time.
This saves a subsequent `stat()` call on the source FD in the btrfs
reflink or splice code. Every little helps.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Something has changed recently which causes this error to now be emitted
when building on Windows msys2-mingw32:
```
../gio/gwin32networkmonitor.c: In function 'win_network_monitor_get_ip_info':
../gio/gwin32networkmonitor.c:92:15: error: storing the address of local variable 'prefix' in '*dest' [-Werror=dangling-pointer=]
92 | *dest = (guint8 *) &prefix.Prefix.Ipv4.sin_addr;
| ~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
```
If `IP_ADDRESS_PREFIX` is defined as a scalar rather than a pointer,
that could explain the problem.
Change the function to always operate on a pointer to avoid any
potential such issues.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
The gio/tests/socket-client.c doesn't use GSocketClient, which makes the
filename confusing. What the file actually tests is the GSocket. Rename
it to socket-testclient.c
The corresponding GSocket server test file naming doesn't conflict with other
class names, but rename it to socket-testserver.c for consistency.
Closes#2855
The file was not listed in `POTFILES.in` (as pointed out by Piotr Drąg
in
fee0a7679a (note_1722885)),
so either it needs to be added to `POTFILES.in` or the translatable
strings need to be removed.
Recent prior art from GTK shows that there’s actually no longer any
point in setting the nick/blurb as no tools use them (and if they did,
it would result in a rubbish user experience). See
https://gitlab.gnome.org/GNOME/gtk/-/issues/4904.
Hence, drop the strings entirely.
See #2991 for tracking this across all of GIO.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2991
If a timeout executes on the same main context iteration as completion
or cancellation of a resolver lookup, `has_returned` will be set
multiple times. That’s fine (the `GCond` will be notified multiple
times, but that’s fine). It was triggering an incorrect assertion, so
remove that.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
The default for the class is still to have no timeout, but it seems more
practical for most use cases to set a non-infinite timeout on the
default resolver.
If applications have a more specific use case, they can change the
timeout or replace the default resolver.
See https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3397#note_1731387
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
If `async_cancel()` was invoked, it would remove the IO watch source,
which would cause the `g_source_remove()` call at the end of `main()` to
warn about an unknown source ID.
Fix that by handling the source as a pointer instead of a handle.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Rather than running lookups in the global shared thread pool belonging
to `GTask`, run them in a private thread pool.
This is needed because the global shared thread pool is constrained to
only 14 threads. If there are 14 ongoing calls to
`g_task_run_in_thread()` from any library/code in the process, and then
one of them asks to do a DNS lookup, the lookup will block forever.
Under certain circumstances, particularly where there are a couple of
deep chains of dependent tasks running with `g_task_run_in_thread()`,
this can livelock the program.
Since `GResolver` is likely to be called as a frequent leaf call in
certain workloads, and in particular there are likely to be several
lookups requested at the same time, it makes sense to move resolver
lookups to a private thread pool.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
This will make it simpler to handle timeouts and cancellation in future,
as all the logic for working out whether to return will all be in one
place, and all the lookup-specific code is now implemented in simple
sync functions which don’t need to care about `GTask`s.
This commit introduces no functional changes, it’s just setting up for
the following commit.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
This introduces no functional changes, but will make a reorganisation of
the code simpler in the next commit.
Rather than dealing with three different closure types, this changes the
code to deal with one which is a tagged union of the three.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
The class and its header are not public, so this should not be an API or
ABI break.
This just simplifies the code a little and allows for easy extension of
the object’s private data in future commits.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Without a timeout, some lookup requests can go on forever, typically due
to bugs in underlying systems.
This can have particularly significant effects on the Happy Eyeballs
algorithm in `GSocketClient`, which relies on multiple name lookups as
its first step.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2866
Track the `GTask`s which are still alive (not finalised) in a shared
list, and provide a secret debugging function for printing that list.
Too often when debugging apps, I have found that a ‘leaked’ object is
actually still (validly) referenced by an ongoing `GTask` which hasn’t
completed for whatever reason. Or I have found that an operation has
obviously stalled, but there are no pointers available to the `GTask`
which is stalled, because it’s being tracked as a collection of closure
pointers from some `GSource` which is hard to get to in the debugger.
It will be very useful for debugging apps, if there’s a list of all the
still alive `GTask`s somewhere. This is that list.
The code is disabled if `G_ENABLE_DEBUG` is not defined, to avoid every
`GTask` construction/finalisation imposing a global locking penalty.
To use the new list, break in `gdb` while running your app, and call
`g_task_print_alive_tasks()`, or inspect the `task_list` manually:
```
(gdb) print g_task_print_alive_tasks()
16:44:17:788 GLib-GIO 5 GTasks still alive:
• GTask 0x6100000ac740, gs_plugin_appstream_setup_async, ref count: 1, ever_returned: 0, completed: 0
• GTask 0x6100000bf940, [gio] D-Bus read, ref count: 2, ever_returned: 0, completed: 0
• GTask 0x6100000aac40, gs_plugin_loader_setup_async, ref count: 1, ever_returned: 0, completed: 0
• GTask 0x61000006d940, gs_plugin_loader_job_process_async GsPluginJobRefine, ref count: 1, ever_returned: 0, completed: 0
• GTask 0x610000118c40, [gio] D-Bus read, ref count: 2, ever_returned: 0, completed: 0
```
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
This commit changes the use of `ngettext` with `g_dngettext`. The
project defined `g_dngettext` (with domain support) provides the same
functionality as `ngettext` with a NULL domain provided. The purpose of
this change is to help address a build error for certain compilers that
trigger a `format-nonliteral` error-promoted-warning when using
`ngettext` (see also [1][2]). The benefit of switching to use
`g_dngettext` is that the function is defined with `G_GNUC_FORMAT`. This
provides a hint to GNU GCC compilers to still sanity check these
arguments, but not generate a `format-nonliteral`.
[1]: 4ae8606b6f
[2]: 0ca660315a
Signed-off-by: James Knight <james.d.knight@live.com>
This reverts commit 4ae8606b6f. The idea
for the change [1] was to address a build error for certain compilers
that trigger a `format-nonliteral` error-promoted-warning since these
compilers do not gracefully support `ngettext` usage. The changes
following a pattern from an old commit [2]; however, James Hilliard has
pointed out these changes do not work as intended. A deeper inspection
of the commit showed that the commit was from an old merge request that
was not pulled in, detailing why the changes did not work (see also
[3][4]).
Manipulating the sockets unit test confirms that the format values no
longer get a proper value:
...
ok 9 /socket/address
ok 10 /socket/unix-from-fd
ok 11 /socket/unix-connection
**
GLib-GIO:ERROR:../gio/tests/socket.c:1493:test_unix_connection_ancillary_data: assertion failed (err == NULL): Expecting one fd, but got %d
(g-io-error-quark, 0)
...
And reverting this change restores the original functionality:
...
ok 9 /socket/address
ok 10 /socket/unix-from-fd
ok 11 /socket/unix-connection
**
GLib-GIO:ERROR:../gio/tests/socket.c:1493:test_unix_connection_ancillary_data: assertion failed (err == NULL): Expecting 1 control message, got 0 (g-io-error-quark, 0)
...
[1]: https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3390
[2]: 44b3d5d80445234041f6c59feb89645f7102c3a4
[3]: https://gitlab.gnome.org/GNOME/glib/-/merge_requests/770
[4]: https://gitlab.gnome.org/GNOME/glib/-/issues/1744
Signed-off-by: James Knight <james.d.knight@live.com>
These make it a bit easier to track the ongoing resolver tasks, as the
tasks and/or their closures are not tracked in a big list somewhere.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
It’s a bad idea to use it without some care for how much it’s being
called in parallel, or dependencies between tasks. If the thread pool
gets exhausted by too many inter-dependent calls to
`g_task_run_in_thread()` then the process will livelock.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Update a series of error messages to use `g_set_error_literal` instead
of `g_set_error`. This should prevent `format-nonliteral` compiler
issues when `-Werror` is configured:
../gio/gunixconnection.c: In function ‘g_unix_connection_receive_fd’:
../gio/gunixconnection.c:183:9: error: format not a string literal, argument types not checked [-Werror=format-nonliteral]
183 | nscm);
| ^~~~
../gio/gunixconnection.c:217:20: error: format not a string literal, argument types not checked [-Werror=format-nonliteral]
217 | nfd);
| ^~~
../gio/gunixconnection.c: In function ‘g_unix_connection_receive_credentials’:
../gio/gunixconnection.c:601:24: error: format not a string literal, argument types not checked [-Werror=format-nonliteral]
601 | nscm);
| ^~~~
This is similar to a previous change [1] made to `gunixconnection.c`.
[1]: 44b3d5d80445234041f6c59feb89645f7102c3a4
Signed-off-by: James Knight <james.d.knight@live.com>
Since commit c0ca3f99 this test is strictly depending on GDesktopAppInfo
that is not defined or available in macos, so skip the test as we do for
windows.
We could have done this at meson level too, but keeping it this way is
probably a better reminder that this should be adapted for such scenario
one day™
See: https://gitlab.gnome.org/GNOME/glib/-/jobs/2753753
The merge request !2848 added code to automatically detect the module
prefix on macOS, with a test for the Mac #define TARGET_OS_OSX. However,
older versions of the SDK (at least 10.11) don't provide this #define,
leading to build failure. If the #define is missing, fall back to
checking TARGET_OS_MAC. On newer SDKs this symbol is also true for
watchOS, etc., but in those situations TARGET_OS_OSX is available.
Various gio modules include gmodule.h that requires the
gmodule-visibility.h to be already built.
To make this easier, just provide a dependency and use it where we are
building modules that do not depend on libgio_dep (that already includes
that).
Fixes: https://gitlab.gnome.org/GNOME/glib/-/issues/2982
The generated gir file marks the size parameter as "out" by default. This is wrong in the context of a caller allocated buffer with a given size. Explicitly marking the size parameter as (in) fixes the issue.
This reverts commit 4cad66580b.
Downgrading the criticals was only temporary. Now we’ve branched for
GLib 2.78, the criticals can be reinstated early this cycle, so people
have the maximum time to fix latent bugs in their code.
Fixes: #2951
The ref on the timeout source owned by `SendMessageData` was being
dropped just after attaching the source to the main context, leaving it
unowned in that struct. That meant the only ref on the source was held
by the `GMainContext` it was attached to.
This ref was dropped when returning `G_SOURCE_REMOVE` from
`send_message_with_reply_timeout_cb()`. Before that happens,
`send_message_data_deliver_error()` is called, which normally calls
`send_message_with_reply_cleanup()` and destroys the source.
However, if `send_message_data_deliver_error()` is called when the
message has already been delivered, calling
`send_message_with_reply_cleanup()` will be skipped. This leaves the
source pointer in `SendMessageData` dangling, which will cause problems
when `g_source_destroy()` is subsequently called on it.
I’m not sure if it’s possible in practice for this situation to occur,
but the code certainly does nothing to prevent it, and it’s easy enough
to avoid by keeping a strong ref on the source in `SendMessageData`.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #1264
It already implicitly held a strong ref on its `GTask` values, but
didn’t have a free function set so that they would be automatically
unreffed on removal from the map.
This meant that the functions handling removals from the map,
`on_worker_closed()` (via `cancel_method_on_close()`) and
`send_message_with_reply_cleanup()` had to call unref once more than
they would otherwise.
In `send_message_with_reply_cleanup()`, this behaviour depended on
whether it was called with `remove == TRUE`. If not, it was `(transfer
none)` not `(transfer full)`. This led to bugs in its callers.
For example, this led to a direct leak in `cancel_method_on_close()`, as
it needed to remove tasks from `map_method_serial_to_task`, but called
`send_message_with_reply_cleanup(remove = FALSE)` and erroneously didn’t
call unref an additional time.
Try and simplify it all by setting a `GDestroyNotify` on
`map_method_serial_to_task`’s values, and making the refcount handling
of `send_message_with_reply_cleanup()` not be conditional on its
arguments.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #1264
This is equivalent to the current behaviour, but a little clearer in its
meaning.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #1264
The ownership transfers in this code are a bit complex, so adding some
extra documentation and `g_steal_pointer()` calls should hopefully help
clarify things.
This doesn’t introduce any functional changes, just code documentation.
Another drive-by improvement in the quest for #1264.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #1264
The existing comment in the code was correct that `data` is freed when
the task callback is called, because `data` is also pointed to by the
`user_data` for the task, and that’s freed at the end of the callback.
So the existing code was correct to take a copy of `data->task` before
calling `g_task_return_*()`.
After calling `g_task_return_*()`, the existing code unreffed the task
(which is correct), but then didn’t clear the `data->task` pointer,
leaving `data->task` dangling. That could cause a use-after-free or a
double-unref.
Avoid that risk by explicitly clearing `data->task` before calling
`g_task_return_*()`.
After some testing, it turns out this doesn’t actually fix any bugs, but
it’s still a good robustness improvement.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #1264
The generated gir file marks the size parameter as "out" by default. This is wrong in the context of a caller allocated buffer with a given size. Explicitly marking the size parameter as (in) fixes the issue.
As explained in the previous commit, GNU Coreutils 9.2 changes the behaviour
of `du --bytes` to only count regular files and symlinks.
The previous commit makes the test pass with GNU Coreutils >=9.2, but the
machine running the tests may have an older version, or perhaps even a
reimplementation such as uutils. So we can't rely on the size returned by `du`
to be the consistent across systems any more.
However, the plus side of the new behaviour is that the size reported by `du`
/ `G_FILE_MEASURE_APPARENT_SIZE` is now well-defined across filesystems
(as the sum of the sizes of regular files & symlinks), so we can hardcode it.
Fixes: https://gitlab.gnome.org/GNOME/glib/-/issues/2965
Since GNU Coreutils 9.2 (commit 110bcd28386b1f47a4cd876098acb708fdcbbb25),
`du --apparent-size` (including `du --bytes`) no longer counts all kinds of
files (directories, FIFOs, etc.), but only those for which `st_size` in
`struct stat` is defined by POSIX, namely regular files and symlinks
(and also rarely supported memory objects).
This aligns the behaviour of GLib's `G_FILE_MEASURE_APPARENT_SIZE` flag
with the new GNU Coreutils `du` and correct POSIX use.
Note that this may be a breaking change for some uses.
Link: https://lists.gnu.org/archive/html/bug-coreutils/2023-03/msg00007.html
Fixes: https://gitlab.gnome.org/GNOME/glib/-/issues/2965
Warn when the boolean return isn't used, since we may not initialize
the out arguments in the FALSE case. Update all internal callers to
use the return value. They were already safe, but users outside GLib
may not be.
Previously, `-Wl,--export-dynamic` was in `Libs` key of `gmodule-2.0.pc`,
even though `-Wl` is a compiler flag, rather than a linker one.
This caused issues with API reference builds in evolution-data-server,
which passes the output of `pkg-config --libs` through `--ldflags`
argument of `gtkdoc-scan`, which are forwarded unchanged to `ld`:
ld: unrecognized option '-Wl,--export-dynamic'
Let’s move the flag to `Cflags` so that the compiler can deal with it.
https://gitlab.gnome.org/GNOME/evolution-data-server/-/issues/463
Add support for it, but don’t use it anywhere yet — this is an API
addition, but currently doesn’t cause any functional changes. It’ll be
used in the next commit.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
The `inotify_init1()` API has supported this flag for a long time
(possibly since it was first introduced, although I haven’t bothered
doing the archaeology).
This saves a syscall when first connecting to inotify.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Both `GPollableInputStream` and `GPollableOutputStream` are dynamic
interfaces, in that their implementation on a class may only be
functional if certain prerequisites are met at runtime. For example,
a `GConverterInputStream` is only pollable if its base stream is
pollable, and that’s determined at runtime rather than compile time.
As such, both interfaces have a `can_poll()` method. If that method
returns `FALSE`, the behaviour of all other methods on the interface is
undefined.
That was mentioned in the documentation for `can_poll()`, but not any of
the other documentation for the interfaces, which made it a bit hard to
find.
Mention it more widely.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2952
If the libc and kernel support `SOCK_NONBLOCK`, we can specify that in
the `socket()` flags, and avoid a subsequent call to `fcntl()` to set
`O_NONBLOCK`.
For modern Linux distributions, this will save a syscall when creating a
socket.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
This should split the code up into logical blocks a bit better, and make
it a bit easier to see what the test is doing at a glance.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
This makes the exit conditions for each main loop clearer, and
eliminates use of global variables. It introduces no functional changes.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
If the first part of the test takes less than 3s (which is normal), the
timeout for it is not removed, and could spuriously fire during the
second part of the test, causing a false failure.
Instead of relying on source IDs, just use (and explicitly destroy) a
`GSource` for the timeouts.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
The test thought that calling `g_app_info_get()` was a bit of a hack,
but actually it (or calling another `g_app_info_*()` function) is the
right way to use the `GAppInfoMonitor` API.
See the documentation improvements a couple of commits back for details.
The remaining FIXME higher up in the test should probably be fixed by
getting `g_app_info_monitor_get()` to arm the signal. That requires
changes in `g_app_info_monitor_get()` to call `desktop_file_dir_init()`.
That will have to happen another time.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #799
This is put together through git archaeology:
```
git log gio/tests/appmonitor.c
```
The following commits were too trivial to have meaningful copyright:
- 54047080e9
- 4e7d22e268
- f2c1cfe8c7
- f8f344923e
- 3ce00b29ec
- 3468369625
- e9d9edde82
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #1415
This partially reverts ed8e86a7d4.
The change to add the criticals (commit ed8e86a7d4) is correct, but
landed too late in the cycle. Let’s downgrade the criticals to debugs
for now, to stop applications seeing a lot of new criticals in their
output. Those criticals are particularly disruptive for command line
applications and unit tests.
Early in the next cycle, the debugs will be re-upgraded to criticals.
This will give applications a whole additional cycle to fix their
ambiguous use of API.
It turned out that a lot of applications have latent bugs around
calling `g_file_info_get_*()` without checking whether an attribute
is set first, and were hence relying on the ‘unknown’ return value
also being an appropriate default for them.
This was compounded by the fact that several non-local GVFS backends
were not setting `GFileInfo` attributes all the time, which caused the
‘missing attribute’ code path to be hit more frequently. For example,
they would only call `g_file_info_set_is_hidden()` with a true value and
never bother with a false one.
It was further compounded by the fact that, while this change landed for
the 2.75.4 release, there did not seem to be extensive integration
testing of that release, and distributions and downstreams went straight
to 2.76.0. That meant we missed the window between 2.75.4 and 2.76.0 to
change, fix or revert this behaviour. GLib relies on distros and
downstreams doing integration testing of unstable releases. We test with
downstream GNOME as part of gnome-build-meta, but do not have the
resources to do integration testing for everybody.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
See: #2907
See: #2932
See: #2934
See: #2945
See: #2948
This is written in pseudocode C which omits all the callback boilerplate
for the async calls. This should hopefully make the overall structure of
the loop more obvious.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #352
As suggested on #352 by Owen Taylor (commit put together by Philip
Withnall, but in Owen’s name as it’s his wording).
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #352
Before commit ed8e86a7d4, this function would have silently returned a
zero-valued `GTimeVal` if the correct attributes weren’t present.
That partially regressed in commit ed8e86a7d4, which made it return with
a critical warning, but without zeroing the `GTimeVal`. The critical
warning can be ignored by users (it doesn’t abort the process unless
`G_DEBUG=fatal-criticals` is set), but the change in behaviour of
zeroing the `GTimeVal` could cause bugs.
See: #2907
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
`gio info` currently prints ‘display name:’ twice. One of those should
be ‘edit name:’ — this regressed in commit
a374b7c806.
Various translations still have the old string, but some unfortunately
do not, so this is effectively a new translatable string again.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
This fixes bug #624696.
Incorporates a more recent change from 1dc774a653 to drop the
`g_type_init()` call, and reformats the indentation a bit.
Fixes: #322
They just listed built files. Since the move to Meson, these are all
kept in a separate build directory, not the source tree, so don’t need
to be ignored.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
While we can’t check for any events on it, this at least tests that
creating a file monitor works. It should cover the fix from the previous
commit.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: !3241
This should catch regressions in the critical warning fixed in the
previous commit.
The launch has to have several conditions:
- Session bus is running (to avoid the launch happening via the spawn
codepath)
- Use a non-existent D-Bus name (to trigger a launch error)
- Use a launch context (to hit the critical warning code path)
- Not have a startup ID specified in the platform data — this implies
having an empty launch context
- Use an async launch, as that provides an error handling path
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
It’s possible for the startup ID to be `NULL` if one wasn’t provided in
the platform data passed to `launch_uris_with_dbus()`.
Passing `NULL` to `g_app_launch_context_launch_failed()` causes a
critical warning.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
The timeout runs for the entire duration of the test, which is a
function that Meson’s test harness already provides for us.
Meson’s timeout can be easily adjusted by a factor to allow for running
tests more slowly under valgrind. The timeout in the code cannot, which
leads to spurious failures like
https://gitlab.gnome.org/GNOME/glib/-/jobs/2645271.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
If the timeout callback was executed, it would remove the timeout
source, leaving the `g_source_remove()` call in the main function with a
dangling source ID.
Fixes commit 73205b8bbd.
Spotted in https://gitlab.gnome.org/GNOME/glib/-/jobs/2645271.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Previously it was only being set on non-Windows platforms. For
consistency, always set it on Windows too.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2934
Following on from #2907, set various boolean attributes if they have
been requested, or are known for sure, and their value is `FALSE`.
Previously the `FALSE` value would have been implicitly returned by the
getter function, but now doing that without the attribute being
explicitly set will trigger a critical warning.
*Don’t* set these attributes if their value is unknown or there was an
error querying it.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2934
The `is-backup` attribute isn't currently set on Windows. It would
be nice to set such basic attributes on all platforms. Let's set
the attribute to `FALSE` there.
Currently, the `G_FILE_ATTRIBUTE_STANDARD_IS_BACKUP` attribute is set
only when its value is `TRUE`. This is wrong with the latest changes as
the `GLib-GIO-CRITICAL **: 00:54:07.260: GFileInfo created without
standard::is-backup` errors are printed now from the
`g_file_info_get_is_backup` function among others. Let's set this
aattribute also when it is `FALSE`.
Related: https://gitlab.gnome.org/GNOME/glib/-/issues/2934
The lost+found dir isn't detected as hidden currently. This is regression
caused by the commit 728ad64b. Let's change the code a bit to be sure that
the lost+found dir is marked as hidden again.
When the `g_file_copy` function is used with files on BTRFS, the
`GLib-GIO-FATAL-CRITICAL: GFileInfo created without standard::size`
error is printed. This is because the `g_file_get_size` function
is used to obtain the file size for the progress callback, but it uses
the wrong `GFileInfo` object that is meant for attributes to be copied
with the file. The file size attribute is missing there obviously. Let's
obtain the file size over the `fstat` call the same way as it is done in
the `splice_stream_with_progress` function to get rid of those errors
and to fix the progress reporting.
This fixes:
| ../glib-2.75.3/gio/tests/cxx.cpp: In function 'int main(int, char**)':
| ../glib-2.75.3/gio/tests/cxx.cpp:61:15: error: missing sentinel in function call [-Werror=format=]
| 61 | g_test_init (&argc, &argv, NULL);
if built with musl libc
Signed-off-by: Markus Volk <f_l_k@t-online.de>
Add a missing steal call in `schedule_method_call()`. This introduces no
functional changes, but documents the ownership transfer more clearly.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2924
This `GDBusMethodInvocation` may be shared across threads, with no
guarantee on the strong ref in one thread outlasting any refs in other
threads — so it needs a ref in this helper struct.
This should fix a use-after-free where the `GDBusMethodInvocation` is
freed from `g_value_unset()` after `g_signal_emit()` returns in
`dispatch_in_thread_func()` in one thread; but then dereferenced again
in `g_source_destroy_internal()` from another thread.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2924
The `GDBusInterfaceSkeleton` is already stored as the source object of
the `GTask` here, with a strong reference.
Storing it again in the task’s data struct is redundant, and makes it
look like the `GDBusInterfaceSkeleton` is being used without holding a
strong reference. (There’s not actually a bug there though: the strong
reference from the `GTask` outlives the data struct, so is sufficient.)
Remove the unnecessary helper struct member to clarify the code a bit.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2924
This introduces no functional changes; just made it while trying to
debug issue #2925.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2925
Otherwise it’s possible for it to hang around in the `GMainContext`
after the “send message” operation has finished. In the best case, this
will cause the `GTask` and `GDBusMessage` to not be freed when the
calling code expects. In the worst case, it could cause use-after-free
problems if it derefs allocations which have since been freed.
I have not seen either of these problems in practice, but it would be
best for the code to eliminate the risk of them altogether by explicitly
destroying the source when the operation is finished.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2925
This doesn’t introduce any functional changes, but should make the code
a little clearer.
Drive-by improvements while trying to debug #1264.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #1264
This introduces no functional changes, but makes it a little clearer how
the ownership of these `GDBusMessage` instances works. The free function
is changed to `g_clear_object()` to avoid the possibility of somehow
using the messages after freeing them.
Basically just some drive-by docs improvements while trying to debug
issue #1264.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #1264
This didn’t actually cause any observable bugs, since the structures of
`PropertyData` and `PropertyGetAllData` were equivalent for the members
which the free function touches.
Definitely should be fixed though.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
This appears to fix an intermittent failure seen when sending a D-Bus
message with either of a cancellable or a timeout set.
In particular, I can reliably reproduce it with:
```
meson test gdbus-test-codegen-min-required-2-64 --repeat 10000
```
It can be caught easily with asan when reproduced. Tracking down the
location of the refcount mismatch was a little tricky, but was
simplified by replacing a load of `g_object_ref (message)` calls with
`g_dbus_message_copy (message, NULL)` to switch `GDBusMessage` handling
to using copy semantics. This allowed asan to home in on where the
refcount mismatch was happening.
The problem was that `send_message_data_deliver_error()` takes ownership
of the `GTask` passed to it, but the
`send_message_with_replace_cancelled_idle_cb()` and
`send_message_with_reply_timeout_cb()` functions which were calling it,
were not passing in a strong reference as they should have.
Another approach to fixing this would have been to change the transfer
semantics of `send_message_data_deliver_error()` so it was `(transfer
none)` on its `GTask`. That would probably have resulted in cleaner
code, but would have been a lot harder to verify/review the fix, and
easier to inadvertently introduce new bugs.
The fact that the bug was only triggered by the cancellation and timeout
callbacks explains why it was intermittent: these code paths are
typically never hit, but the timeout path may sometimes be hit on a very
slow test run.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #1264
mkstemp-like family of functions also use g_open () under the hood so
they should pass the O_CLOEXEC flag there for race-free setting of the
close-on-exec flag.
setmntent () call uses the same mode flag set as fopen (), so it should
also include the "e" mode flag for race-free setting of the close-on-exec
flag.
All Unix CRTs examined: glibc, musl, BSDs, Apple libc, Android bionic
ignore unknown fopen () mode flags, so this flag can be added
unconditionally for Unix builds.
Only Windows CRT is intolerant of these, so the single case in
g_dbus_address_connect () where the fopen () call is shared between Unix
and Windows needs appropriate platform-specific handling.
Skipped the call sites in libcharset and xdgmime copylibs.
The `equal_func` closure can already have all required information
available without the item, and passing the item via the closure instead
of an explicit parameter is more natural for languages that have a
concept of closures that can capture variables.
Otherwise, the content of the buffer is thrown away when switching
from reading via a GDataInputStream to unbuffered reads when waiting
for the "BEGIN" line.
(The code already tried to protect against over-reading like this by
using unbuffered reads for the last few lines of the auth protocol,
but it might already be too late at that point. The buffer of the
GDataInputStream might already contain the "BEGIN" line for example.)
This matters when connecting a sd-bus client directly to a GDBus
client. A sd-bus client optimistically sends the whole auth
conversation in one go without waiting for intermediate replies. This
is done to improve performance for the many short-lived connections
that are typically made.
This reverts commit 27bee8fe5d.
Inevitably, despite testing the CI multiple times before merging commit
27bee8fe, the CI is now failing again in the `socket` test due to (what
I continue to assume is) the kernel regression:
https://gitlab.gnome.org/martinpitt/glib/-/jobs/2585332
In order to unblock development on `main` expediently, I guess I’ll just
revert the revert.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Reopens: #2879
It’s not meant to be exposed publicly yet (we’re not ready to stabilise
it), but it was incorrectly decorated with `GLIB_AVAILABLE_IN_2_76`.
We can’t remove the decorator and use it that way, as it’s called in
libgio, so we have to expose it using `GLIB_PRIVATE_CALL()`.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2876
Don’t just set them when they’re true and rely on their non-presence
being evaluated to `FALSE`. That means that they erroneously don’t get
returned in `g_file_info_list_attributes()`.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2907
`g_file_info_get_is_hidden()` should not be called without checking the
attribute is set first, just as with the calls higher up in this code.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2907
As documented in a previous commit, these functions should not be called
without the right attributes being present in the `GFileInfo`. Add
critical warnings to make this more obvious.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2907
It doesn’t make sense to (for example) call `g_file_info_get_name()` if
the `GFileInfo` doesn’t contain `G_FILE_ATTRIBUTE_STANDARD_NAME`, given
that building the `GFileInfo` is typically a static process and entirely
under the control of the programmer.
By being this restrictive, we avoid having to return ‘unknown’ values
for some of these standard APIs, particularly the numeric ones such as
`g_file_info_get_size()`. If APIs like that were to work correctly in
the face of a `GFileInfo` without `G_FILE_ATTRIBUTE_STANDARD_SIZE`
specified, they’d have to be able to return a value to indicate the
attribute is missing. Returning `0` or `G_MAXSIZE` to indicate that
would be ambiguous.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2907
Since gmodule-visibility.h is now a custom target and produced at
buildtime, it might not always exist in time for use in other source
files. This was the case for gio-inotify.
Add it as an additional source file to ensure in-time generation.
When gio monitors a directory, it will delete the extra "/" at the end
of the directory string, but when the directory is "/", this will cause
the modified directory string to be empty, and eventually the
monitoring will fail. The solution is to delete only if the directory
string length is greater than 1.
Currently, inbuf_size and outbuf_size are not documented as not
nullable, but they are expected to be so, which might lead to unexpected
crashes. Moreover, outbuf itself is also expected to not be null, so
this commit adds the appropriate GI annotations and early returns on
failed preconditions.
LLVM objcopy's --strip-all is more aggressive that GNU objcopy --strip-all
and will remove everything that is not actually used. In this case we
see the following error:
`error: 'gio/tests/test_resources.o': Symbol table has link index of 5 which is not a valid index`
Fix this by only removing debug symbols instead of all unused symbols and
sections.
Helps: https://gitlab.gnome.org/GNOME/glib/-/issues/2720
Unlike GNU ld which has a default target architecture, ld.lld is always a
cross-linker and has the same behaviour for all targets. If you don't tell
ld.lld what the target architecture is it can't infer the right ELF flags
for the resulting object file.
```
$ ~/cheri/output/sdk/bin/ld -r -b binary gio/tests/test5.gresource -o gio/tests/test_resources.o -v
LLD 14.0.0 (compatible with GNU linkers)
ld: error: target emulation unknown: -m or at least one .o file required
```
As you can see from the error message it can't infer the target
architecture (you need a least one valid .o file or the -m flag).
If you use the compiler instead of directly invoking the linker it will
pass the appropriate flags:
```
$ ~/cheri/output/sdk/bin/clang -r -Wl,-b,binary gio/tests/test5.gresource -o gio/tests/test_resources.o -v
clang version 14.0.0 (https://github.com/CTSRD-CHERI/llvm-project.git ff66b683475fc44355b2010dbcbe1202d785e6f8)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /home/alexrichardson/cheri/output/sdk/bin
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/10
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/11
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/12
Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/12
Candidate multilib: .;@m64
Selected multilib: .;@m64
"/home/alexrichardson/cheri/output/sdk/bin/ld" --eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 -o gio/tests/test_resources.o -L/usr/lib/gcc/x86_64-linux-gnu/12 -L/usr/lib/gcc/x86_64-linux-gnu/12/../../../../lib64 -L/lib/x86_64-linux-gnu -L/lib/../lib64 -L/usr/lib/x86_64-linux-gnu -L/usr/lib/../lib64 -L/home/alexrichardson/cheri/output/sdk/bin/../lib -L/lib -L/usr/lib -r -b binary gio/tests/test5.gresource
❯ file gio/tests/test_resources.o
gio/tests/test_resources.o: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), not stripped
```
This works for most architectures, but ones that need additional metadata
sections to encode the used ABI, etc. will require a different approach
using .incbin. However, that is a change for another MR.
Partially fixes: https://gitlab.gnome.org/GNOME/glib/-/issues/2720
In case the OS does not support epoll and kqueue, we get the warning:
gio/tests/pollable.c: In function ‘test_pollable_unix_nulldev’:
gio/tests/pollable.c:266:7: warning: unused variable ‘fd’
[-Wunused-variable]
266 | int fd;
Get rid of it.
Signed-off-by: Sergey Bugaev <bugaevc@gmail.com>
Now that there is g_string_free_and_steal (), we can use it instead of
the older g_string_free (_, FALSE). Make sure to use its return value
while doing so, as opposed to manually accessing string->str, to avoid
compiler warnings and make the intent more explicit.
This is all done in preparation for making g_string_free (_, FALSE) warn
on unused return value much like g_string_free_and_steal (), which will
happen in the next commit.
Signed-off-by: Sergey Bugaev <bugaevc@gmail.com>
Spawning a process correctly is a lot more complicated than just bunging
an argument onto the return value from this function.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2901
Fix the tests, by allocating the structure.
==121338==ERROR: AddressSanitizer: stack-use-after-scope on address 0x7ffe44018610 at pc 0x00000040ff71 bp 0x7ffe440178f0 sp 0x7ffe440178e8
READ of size 8 at 0x7ffe44018610 thread T0
#0 0x40ff70 in test_launch_uris_with_terminal ../gio/tests/desktop-app-info.c:1393
#1 0x7efd97b831e8 in test_case_run ../glib/gtestutils.c:2947
#2 0x7efd97b831e8 in g_test_run_suite_internal ../glib/gtestutils.c:3037
#3 0x7efd97b82d23 in g_test_run_suite_internal ../glib/gtestutils.c:3056
#4 0x7efd97b82d23 in g_test_run_suite_internal ../glib/gtestutils.c:3056
#5 0x7efd97b82d23 in g_test_run_suite_internal ../glib/gtestutils.c:3056
#6 0x7efd97b84189 in g_test_run_suite ../glib/gtestutils.c:3136
#7 0x7efd97b842c5 in g_test_run ../glib/gtestutils.c:2248
#8 0x4055bc in main ../gio/tests/desktop-app-info.c:1901
#9 0x7efd9564a50f in __libc_start_call_main (/lib64/libc.so.6+0x2750f)
#10 0x7efd9564a5c8 in __libc_start_main_alias_1 (/lib64/libc.so.6+0x275c8)
#11 0x4059f4 in _start (/home/elmarco/src/gnome/glib/build/gio/tests/desktop-app-info+0x4059f4)
Address 0x7ffe44018610 is located in stack of thread T0 at offset 128 in frame
#0 0x404d1f in main ../gio/tests/desktop-app-info.c:1823
This frame has 6 object(s):
[48, 52) 'argc' (line 1821)
[64, 72) 'path' (line 1870)
[96, 104) 'argv' (line 1822)
[128, 144) '<unknown>' <== Memory access at offset 128 is inside this variable
[160, 176) '<unknown>'
[192, 288) 'supported_terminals' (line 1825)
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
There’s a kernel bug on the CI machines which is causing this test to
fail all the time and it’s getting my goat.
The test can be re-enabled later (by reverting this commit) when the
kernel on the CI VM host is fixed. I don’t know when that’s going to
happen.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2879
Otherwise if, for whatever reason, the `app` loses its D-Bus name,
`g_application_quit()` is called from `name_was_lost()` before it’s
called from `quit_already()`, and then `quit_already()` does an invalid
read on `app`.
If the name was not meant to be lost at this point in the test, the
subsequent `g_assert_false (name_lost)` will catch that, so this change
shouldn’t cause the test to pass unnecessarily.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
In all these cases we don't really care about running the test file,
while building and basic execution it is relevant.
Also they don't support TAP at all.
Meson supports tap protocol results parsing, allowing us to track better
the tests that are running (and the ones that are actually skipped) without
manually parsing the test output.
However this also implies that using the verbose mode for a test doesn't
show its output by default (unless there are failures).
We may not be able to fix GTasks broken design,
but at least we should document it and not let
users stumble into this bear trap without warning.
Helps: #1346
Due to an oversight (I guess), per-desktop default values (which come
from override files such as this one:
https://github.com/endlessm/gnome-shell/blob/master/data/00_org.gnome.shell.gschema.override)
were not checked when getting a GSettings value via a `GSettingsAction`.
Per-desktop default values are correctly returned via all other
GSettings query paths (see calls to
`g_settings_schema_key_get_translated_default()`).
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
This reverts commit da7a31a052. The renaming of parameters implicitly introduced "closure" annotations in the documentation which are wrong on callbacks.
We cannot use `gvisibility_h` for different visibility header files; you
never know when you're going to refer to the variable again, and
projects might end up needing to retrieve the variable contents—like,
for instance, gobject-introspection using glib as a subproject.
Fix a regression that appeared after adding support for nanosecond
timestamps to set_mtime_atime(). User-visible effect: when copying a
file from a gvfs MTP mountpoint to the local filesystem, the file's
mtime is set to 0.
This behavior happens when setting G_FILE_ATTRIBUTE_TIME_MODIFIED first,
then G_FILE_ATTRIBUTE_TIME_MODIFIED_USEC. Setting the second attribute
ends up in set_mtime_atime() with mtime_usec_value set, and mtime_value
== NULL. When mtime_value is NULL, the tv_sec part of the timestamp
should be fetched by lazy_stat(), but set_mtime_atime() fails to assign
it properly, and tv_sec stays at 0, leading to losing the main part of
the timestamp.
Fix the issue by setting times_n[1].tv_sec to the value fetched from
lazy_stat().
Fixes: b33ef610de ("Add functionality to preserve nanosecond timestamps")
Fixes: 15cb123c82 ("glocalfileinfo: don't call both utimes and utimensat")
Signed-off-by: Maxim Mikityanskiy <maxtram95@gmail.com>
`search_token` cannot be `NULL` at this point (guaranteed by all the
current call sites of `desktop_file_dir_unindexed_search()`), so remove
an unnecessary `NULL` check.
Add an assertion to make the nullability clear.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Coverity CID: #1502196, #1502193
If the port is not specified, then a default port should be assumed.
This is how everybody expects URIs to work and it's how GProxyResolver
should work too.
We already have lots of tests to ensure this works as expected; however,
the documentation currently does not allow it. Change the documentation
to match reality.
Fixes#2832
When launching a registered handler we compose the command-line
string using the registered command-line template. Applications
expect files in their command-line as local paths rather than
complete URI strings.
For example,
"Program.exe" "%1"
Should expand to
"Program.exe" "C:\file.dat"
Rather than
"Program.exe" "file:///C:\file.dat"
Fixes https://gitlab.gnome.org/GNOME/glib/-/issues/2843
Substring matches can have too much unwanted results, while prefix
matches is more accurate but cannot handle some special cases, this
commit combines them by adding a match_type member, then sort and group
result with both categories and match types.
For the same category, prefix matched results will be put in the first
group and substring matched results will be put in the second group.
We eventually need to return them as an array anyways.
Sadly we can't just reuse such memory because each element is a pointer and
not a guchar, but still we can be cheaper in various operations.
I noticed this when running the test on an Arm Morello system where varargs
have bounds. g_variant_new() was trying to read an integer using va_arg(),
but since there was no argument it resulted in a bounds errors there.
On most other architectures this will just read whatever value is contained
in the next argument register and is not something that ASan can detect, so
it never resulted in test failures.
When a cancellable is cancelled when we call g_cancellable_connect we
used to immediately call the provided callback, while this is fine we
actually had race in case the cancellable was about to be reset or in
the middle of a cancellation.
In fact it could happen that when we released the mutex, another thread
could reset the cancellable just before the callback is actually called
and so leading to call it with g_cancellable_cancelled() == FALSE.
So to handle this, make disconnect and reset function to wait for
connection emission to finish, not to break their assumptions.
This can be tested using some "brute-force" tests where multiple threads
are racing to connect and disconnect while others are cancelling and
resetting a cancellable, ensuring that all works as we expect.
This solves problems with validating untrusted inputs from D-Bus, where
invalid numbers of added and removed menu entries, and positions, could
be specified.
Original patch from
https://bugzilla.gnome.org/show_bug.cgi?id=728733#c7, tweaked by Philip
Withnall to add a few code comments and make
`G_MENU_EXPORTER_MAX_SECTION_SIZE` public so callers can check their
inputs against it if they want. Also tweaked to use `g_warning()` instead
of the nonexistent `g_dbus_warning()`.
Fixes: #861
If it takes one more `GMainContext` cycle than expected for the
`activate` signals to be handled, the `GApplication` under test can be
released too early, and the test will fail due to not seeing a high
enough value of `n_activations`.
Hopefully avoid that by moving the release to a low priority idle
callback.
This fix is only hopeful because I’ve only been able to reproduce the
failure on FreeBSD CI and not locally.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2835
The timeout is just to stop the test hanging forever, so there’s no need
for it to be so short. It’s caused at least one spurious CI failure:
https://gitlab.gnome.org/GNOME/glib/-/jobs/2445023.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2837
GDesktopAppInfo never failed in the most simple of the cases: when a
desktop file or a command line app info was pointing to an invalid
executable (for the context).
The reason for this is that we're launching all the programs using
gio-launch-desktop which will always exist in a sane GLib installation,
and thus our call to execvp won't ever fail on failure.
This was partially mitigated by not allowing to create a desktop app
icon using a non-existent executable (even if not fully correctly) but
still did not work in case a custom PATH was provided in the launch
context.
To avoid this, use g_find_program_for_path() to find early if a program
that we're about to launch is available, and if it's not the case return
the same error that g_spawn_async_with_fds() would throw in such cases.
While this is slowing a bit our preparation phase, would avoid to leave
to the exec function the job to find where our program is.
Add tests simulating this behavior.
We used to launch applications with terminals using the normal program
finder logic that did not consider the context path nor the desktop file
working dir. Switch to g_find_program_for_path() to find terminals so we
can ensure that both conditions are true.
Update tests to consider this case too.
The platform data comes from the parent process, which should normally
be considered trusted (if we don’t trust it, it can do all sorts of
other things to mess this process up, such as setting
`LD_LIBRARY_PATH`).
However, it can also come from any process which calls `CommandLine`
over D-Bus, so always has to be able to handle untrusted input. In
particular, `v`-typed `GVariant`s must always have their dynamic type
validated before having values of a static type retrieved from them.
Includes unit tests.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #1904
They come from an external process, so they must be validated.
In particular, it’s always easy to forget to validate the type of a
`GVariant`, and just try to get the stored value using a well-known
type; but that’s a programming error if the `GVariant` actually stores a
different type. Always check the variant type first if loading from a
`v`.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #1904
These actions are activated as a result of receiving the `ActionInvoked`
signal from `org.freedesktop.Notifications`. As that’s received from
another process over D-Bus, it’s feasible that it could be malformed.
Without validating the action and its parameter, assertions will be hit
within the `GAction` code.
While we should be able to trust whatever process owns
`org.freedesktop.Notifications`, it’s possible that’s not the case, so
best validate what we receive.
Includes unit tests.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #1904
This test is fairly pointless, but puts the infrastructure in place for
adding more tests for `GFdoNotificationBackend` in upcoming commits.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #1904
Invoking an action on a notification should remove it (by default,
unless the `resident` hint is set, but GLib doesn’t currently support
that).
If, somehow, an invalid action is invoked on the notification, that
shouldn’t cause it to be removed though, because no action has taken
place. So change the code to do that.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
As with the previous commit, the arguments to `ActivateAction` have to
be validated before being passed to `g_action_group_activate_action()`.
As they come over D-Bus, they are coming from an untrusted source.
Includes unit tests for all D-Bus methods on `GApplication`.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #1904
The action name, parameter and new state are all controlled by an
external process, so can’t be trusted. Ensure they are validated before
being passed to functions which assert that they are correctly typed and
extant.
Add unit tests.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #1904
Some applications (eg., gnome-photos) really want a large thumbnail,
if one can be created. Simply falling back to a smaller one (probably
created by an old nautilus), without giving the application a chance
to create a bigger thumbnail, is undesirable because they will appear
fuzzy.
Therefore, at separate attribute sets for all the thumbnail sizes
that are supported in the spec: normal/large/x-large/xx-large.
The old attribute will now return by default the biggest available, as
it used to be, but also including the x-large and xx-large cases.
Co-Authored-by: Marco Trevisan <mail@3v1n0.net>
Fixes: #621
In case they differ from the defaults, we probably want to ignore them
when listing filesystems which are interesting to the user.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
This reworks commit 20e1508e6e, for two
reasons:
- Upstream dbus.git now does the same (although this isn’t yet reflected
in the online version of the D-Bus Specification); see
https://gitlab.freedesktop.org/dbus/dbus/-/merge_requests/209.
- It allows local-prefix (e.g. jhbuild) builds of GLib to build in a
custom prefix while still interacting with system services using the
system-wide `/run` directory. To do so, pass `-Druntime_dir=/run` to
meson configure.
As documented in the `NEWS` file in
https://gitlab.freedesktop.org/dbus/dbus/-/merge_requests/209, it’s only
valid to use `/run` – rather than `/var/run` – for D-Bus if the two
paths are interoperable. i.e. `/var/run` should be a symlink to `/run`,
and the D-Bus daemon should be configured to put its socket there.
This commit deliberately doesn’t introduce a special `system_socket`
configure option for specifying where the D-Bus system socket lives, as
that would only be useful for a distribution which sets `runstatedir` to
something other than `/var/run` or `/run`, which seems unlikely. We
could add such an option in future, though, if a distribution comes
forward with such a requirement.
See discussion on
https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3095#note_1605502.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
under cygwin socklen_t is signed which leads to warnings like:
warning: comparison of integer expressions of different signedness:
‘long unsigned int’ and ‘socklen_t’ {aka ‘int’} [-Wsign-compare]
In both cases we compare against some small fixed sizes, so cast them
to socklen_t.
cygwin defines socklen_t as int, unlike everywhere else where it is uint32_t (afaics),
so signed vs unsigned.
The recently added -Werror=pointer-sign in 4353813058
makes the build fail under cygwin now with something like:
error: pointer targets in passing argument 5 of ‘getsockopt’ differ in signedness [-Werror=pointer-sign]
This changes guint to socklen_t where needed for getsockname, getpeername and getsockopt.
Do not search in path for snapctl to avoid it to be potentially
overridden by changing the PATH env variable.
Still allow testing by using an ifdef to check if we're building for the
test files or not.
Test all the snap cases and the unknown sandbox one.
We need to use different test processes as we initialize the portal
type early enough that it can't be changed later.
This is of particular use in the gsettings backend, which is currently using
dconf for all snaps.
Fully confined snaps should use the keyfile backend, as Flatpaks do.
Co-Authored-by: Marco Trevisan <mail@3v1n0.net>
Classic snaps are just a kind of packages with no sandbox at all, so
there's no point to mark them as sandboxed.
In this way we can just do IO checks once without having to multiply
them.
Co-Authored-by: Robert Ancell <robert.ancell@canonical.com>
This reverts commit 7e3e591d43.
The freedesktop SDK, which is used by gnome-build-meta, only has Meson
0.63. Bumping GLib’s Meson dependency to 0.64 means that, at the moment,
GLib is not buildable in gnome-build-meta and hence can’t be tested in
nightly pipelines against other projects, etc.
That’s bad for testing GLib.
It’s arguably bad that we’re restricted to using an older version of
Meson than shipped by Debian Testing, but that’s a separate discussion
to be had.
Revert the Meson 0.64 dependency until the freedesktop SDK ships Meson ≥
0.64. This also means reverting the simplifications to use of
`gnome.mkenum_simple()`.
See https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3077#note_1601064
This reverts commit 19353017a7.
The freedesktop SDK, which is used by gnome-build-meta, only has Meson
0.63. Bumping GLib’s Meson dependency to 0.64 means that, at the moment,
GLib is not buildable in gnome-build-meta and hence can’t be tested in
nightly pipelines against other projects, etc.
That’s bad for testing GLib.
It’s arguably bad that we’re restricted to using an older version of
Meson than shipped by Debian Testing, but that’s a separate discussion
to be had.
Revert the Meson 0.64 dependency until the freedesktop SDK ships Meson ≥
0.64. This also means reverting the simplifications to use of
`gnome.mkenum_simple()`.
See https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3077#note_1601064
This reverts commit 756b424cce.
The freedesktop SDK, which is used by gnome-build-meta, only has Meson
0.63. Bumping GLib’s Meson dependency to 0.64 means that, at the moment,
GLib is not buildable in gnome-build-meta and hence can’t be tested in
nightly pipelines against other projects, etc.
That’s bad for testing GLib.
It’s arguably bad that we’re restricted to using an older version of
Meson than shipped by Debian Testing, but that’s a separate discussion
to be had.
Revert the Meson 0.64 dependency until the freedesktop SDK ships Meson ≥
0.64. This also means reverting the simplifications to use of
`gnome.mkenum_simple()`.
See https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3077#note_1601064
Meson now uses find_program() to get glib-mkenum from glib instead of
from system. That was already fixed at least in >=0.60 which is our
current minimum requirement.
This is a spiritual follow-up to commit 8cff531520, which
added `G_TEST_OPTION_ISOLATE_DIRS` to the `gdbus-connection-flush` test
to avoid its D-Bus cookie lock file from being erroneously deleted by
other tests running in parallel.
The same failure mode could affect any of the other D-Bus tests which
connect to a bus. As an easy fix, enable `G_TEST_OPTION_ISOLATE_DIRS`
for all of them.
The only test it’s not (yet) enabled for is `gdbus-address-get-session`
as that messes around with `XDG_RUNTIME_DIR` to test finding the session
bus. It might be possible to use `G_TEST_OPTION_ISOLATE_DIRS` with it,
but that would take longer than I have right now.
In any case, the more tests (which try to connect to a bus) that this is
enabled for, the lower the chances of spurious test failure due to them
conflicting over shared resources.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Because Meson complains about using `configure_file(copy: true)`.
Includes improvements by Xavier Claessens.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
This is deprecated since Meson 0.62.0, since Meson does this
automatically for us.
This fixes a Meson configure warning.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
It sometimes fails under valgrind, and is pointless: if the test is
wedged, it’s better to catch that with the timeout at the level of
`meson test`, which can be tailored (using `-t`) to the test environment
and wrapper.
See https://gitlab.gnome.org/GNOME/glib/-/merge_requests/2961#note_1600072
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Instead, iterate the `GMainContext` directly. This allows tests on
asynchronously returned values to be done in the actual test function,
rather than a callback, which should make the tests a little clearer.
This introduces no functional changes.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
This makes the code a little easier to understand and allows the kernel
a little bit more leeway in scheduling the callback, which is fine
because we don’t need high accuracy here.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
`g_notification_backend_new_default()` adds a reference on
`backend->dbus_connection` (if non-`NULL`), but nothing ever unreffed
that.
Fix that by adding a dispose method.
In practice this is not really a problem, because the notification
backend is held alive by a `GApplication`, which lives as long as the
process. It’ll be a problem if someone is to ever add unit tests for
`GNotificationBackend`s though. So let’s fix it.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Add a few missing introspection annotations too.
This doesn’t change any of the ownership handling behaviour, just
documents what’s there. What’s there seems to be correct, to the extent
that I can see.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
The code is correct, but from a quick read-through it wasn’t entirely
clear to me how it handled floating `GVariant`s in object state or the
`parameter` argument.
Add an assertion and some comments to hopefully clarify things a little.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Do not use can_run_host_binaries() as it returns true even though
custom_target() does not currently correctly wrap target-built
tool binaries with exe_wrapper so they can be run on the host.
See https://github.com/mesonbuild/meson/issues/11029
Building GLib 2.75.0 on Linux adds various inotify-related internal
symbols to the ABI, which doesn't seem to have been intentional.
I went through the other libraries in the build system, and it looks
as though the BSD kqueue backend would have the same problem.
GNU symbol visibility probably doesn't do anything for gio/win32, but
for completeness I've set that to use hidden symbols too, on the basis
that it'll be easier to get this right if we're consistent.
Resolves: https://gitlab.gnome.org/GNOME/glib/-/issues/2811
Signed-off-by: Simon McVittie <smcv@collabora.com>
This typically indicates a bug in the program, where a GTask has been
created, but a bug in the control flow has caused it to not return a
value.
There is one situation where it might be legitimate to finalise a GTask
without returning: if an error happens in your *_async() start function
after you’ve created a GTask, but before the async operation returns to
the main loop; and you report the error using g_task_report_*error()
rather than reporting it using the newly constructed GTask.
Another situation is where you are just using GTask as a convenient way
to move some work to another thread, without the complexity of creating
and running your own thread pool. GDBus does this with
g_dbus_interface_method_dispatch_helper(), for example.
In most other cases, it’s a bug. Emit a debug message about it, but not
a full-blown warning, as that would create noise in the legitimate
cases.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
the gio dbus codegen test has 10 test cases in it.
Each test case is given 100 seconds to complete.
That is far longer than they should need.
Furthermore, the entire test is only given 60s
to complete.
This commit makes the internal timeout more consistent
with the external timeout, by giving each of the 10
test cases 6 seconds instead of 100s.
That’s what xdgmime uses for zero-sized files (see `XDG_MIME_TYPE_EMPTY`).
Historically, GLib explicitly used `text/plain` for empty files, to
ensure they would open in a text editor. But `text/plain` is not really
correct for an empty file: the content isn’t text because there is no
content. The file could eventually become something else when written
to.
Text editors which want to be opened for new, empty files should add
`application/x-zerosize` to their list of supported content types.
Users who want to set a handler for `application/x-zerosize` on their
desktop should use
```sh
gio mime application/x-zerosize # to see the current handler
gio mime application/x-zerosize org.gnome.gedit.desktop # to set it
```
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2777
`HAVE_COCOA` should be used only in the places where we’re actually
depending on the Cocoa toolkit. It should not be used as a general way
of detecting building on a Darwin-based OS such as macOS.
Conversely, there are a few places in the code where we do want to
specifically detect the Cocoa toolkit (and others where we specifically
want to detect Carbon), so keep `HAVE_COCOA` and `HAVE_CARBON` around.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2802
This reverts commit 476e33c3f3.
We’ve decided to remove `G_OS_DARWIN` in favour of recommending people
use `__APPLE__` instead. As per the discussion on #2802 and linked
issues,
* Adding a new define shifts the complexity from “which of these
platform-provided defines do I use” to “which platform-provided
defines does G_OS_DARWIN use”
* There should ideally be no cases where a user of GLib has to use
their own platform-specific code, since GLib should be providing
appropriate abstractions
* Providing a single `G_OS_DARWIN` to cover all Apple products (macOS
and iOS) hides the complexity of what the user is actually testing:
are they testing for the Mach kernel, the Carbon and/or Cocoa user
space toolkits, macOS vs iOS vs tvOS, etc
Helps: #2802
Some of GLib's unit tests are under an apparently GLib-specific
permissive license, vaguely similar to the BSD/MIT family but with the
GPL's lack-of-warranty wording. This is not on SPDX's list of
well-known licenses, so we need to use a custom license name prefixed
with LicenseRef if we want to represent this in SPDX/REUSE syntax.
Most of the newer tests seem to be licensed under LGPL-2.1-or-later
instead.
Signed-off-by: Simon McVittie <smcv@collabora.com>
In g_proxy_resolver_lookup_async() we have some error validation that
detects invalid URIs and directly returns an error, bypassing the
interface's lookup_async() function. This is great, but when the
interface's lookup_finish() function gets called later, it may assert
that the source tag of the GTask matches the interface's lookup_async()
function, which will not be the case.
As suggested by Philip, we need to check for this situation in
g_proxy_resolver_lookup_finish() and avoid calling into the interface
here if we did the same in g_proxy_resolver_lookup_async(). This can be
done by checking the source tag.
I added a few new tests to check the invalid URI "asdf" used in the
issue report. The final case, using async GProxyResolver directly,
checks for this bug.
Fixes#2799
Similar to g_source_set_static_name, this avoids
strdup overhead for debug-only information in
possibly hot code paths.
We also add a macro wrapper for g_task_set_name that
uses __builtin_constant_p to decide whether to use
g_task_set_name or g_task_set_static_name.
We already set names on most sources, this
one was just forgotten. This lets us set
a static name, and prevents g_task_attach_source
from setting a non-static one.
