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
`_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
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
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
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>
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]: 4ae8606b6f80f9764e1f0a82cea7e23c8af487ae
[2]: 0ca660315a9044696f778da087a6e3dd8910a765
Signed-off-by: James Knight <james.d.knight@live.com>
This reverts commit 4ae8606b6f80f9764e1f0a82cea7e23c8af487ae. 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>
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
(cherry picked from commit fe38a02c62c2ceff43a539efa3a31fe2ee72b4fe)
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>
(cherry picked from commit 4ae8606b6f80f9764e1f0a82cea7e23c8af487ae)
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
(cherry picked from commit d296e9455976f1bcf62a83750606befff72aa06e)
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.
(cherry picked from commit f510fa02273e67323c0a91bfb3dca6b00b2147ad)
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
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:
- 54047080e963b2d6c3f966340dcd9d788b73ac9c
- 4e7d22e268a4e06beb1c09585a48288c31004da5
- f2c1cfe8c770f73367a021044bcdda550348714c
- f8f344923eba57ca13d82e53f3e7b82633179f43
- 3ce00b29ec0bb240412506affb5c65bdb18c7ad3
- 346836962521cce76f3cbd53259a985d3bef6a2a
- e9d9edde824df1229bc5539610b98c98013e93aa
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>
This fixes bug #624696.
Incorporates a more recent change from 1dc774a653e992e1 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>
