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
