This was a bug that existed during development of this branch; make sure
it doesn't come back.
This test fails with a use-after-free and crash if we comment out the
part of name_watcher_unref_watched_name() that removes the name watcher
from `map_method_serial_to_name_watcher`.
It would also fail with an assertion failure if we asserted in
name_watcher_unref_watched_name() that get_name_owner_serial == 0
(i.e. that GetNameOwner is not in-flight at destruction).
Signed-off-by: Simon McVittie <smcv@collabora.com>
The vulnerability reported as GNOME/glib#3268 can be characterized
as: these signals from an attacker should not be delivered to either
the GDBusConnection or the GDBusProxy, but in fact they are (in at
least some scenarios).
Reproduces: https://gitlab.gnome.org/GNOME/glib/-/issues/3268
Signed-off-by: Simon McVittie <smcv@collabora.com>
The expected result is that because TEST_CONN_SERVICE owns
ALREADY_OWNED_NAME but not (yet) OWNED_LATER_NAME, the signal will be
delivered to the subscriber for the former but not the latter.
Before #3268 was fixed, it was incorrectly delivered to both.
Reproduces: https://gitlab.gnome.org/GNOME/glib/-/issues/3268 (partially)
Signed-off-by: Simon McVittie <smcv@collabora.com>
Otherwise a malicious connection on a shared bus, especially the system
bus, could trick GDBus clients into processing signals sent by the
malicious connection as though they had come from the real owner of a
well-known service name.
Resolves: https://gitlab.gnome.org/GNOME/glib/-/issues/3268
Signed-off-by: Simon McVittie <smcv@collabora.com>
We will use this in a subsequent commit to prevent signals from an
impostor from being delivered to a subscriber.
To avoid message reordering leading to misleading situations, this does
not use the existing mechanism for watching bus name ownership, which
delivers the ownership changes to other main-contexts. Instead, it all
happens on the single thread used by the GDBusWorker, so the order in
which messages are received is the order in which they are processed.
Signed-off-by: Simon McVittie <smcv@collabora.com>
If a connection has two signal subscriptions active for the same signal,
one with arg0 matching and one without, a signal which doesn’t contain
an arg0 value (i.e. `g_dbus_message_get_arg0()` returns `NULL`) will
cause `NULL` to be passed to `strcmp()` when checking for a match
against the signal subscription which *has* arg0 matching, causing a
crash.
Fix that by adding the obvious `NULL` check, and add a unit test.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Fixes: #3342
D-Bus Activation allows passing an array of parameters. Allow apps to
export actions that accept tuples to match the number of elements in the
parameters so the full potential of the D-Bus interface can be used.
Closes: https://gitlab.gnome.org/GNOME/glib/-/issues/3333
See the code comment. scan-build can’t handle analysis over the
refcounts, so consistently complains about potential use-after-free
errors in the code, essentially because:
* It understands `name_unref()`, but completely ignores `name_ref()`
* The code often calls `name_unref()` on the ‘wrong’ pointer, in the
sense that it knows that if another struct exists, that struct holds
a ref on a `Name`, but without actually having a pointer to the
`Name`. So the code calls `name_unref (name); name_unref (name)`.
That’s valid, but quite understandably looks like a recipe for a
use-after-free.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #1767
scan-build thinks that there can be a `NULL` pointer dereference of
`error` here because it doesn’t understand that the function return
value and `GError` are related: when a valid return value is returned,
the error is `NULL` and vice-versa.
Try and make that clearer to the static analyser by checking whether the
error is `NULL`, rather than the return value.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #1767
scan-build thinks there could be a `NULL` pointer dereference of
`t->data` here. It’s wrong, so add an assertion to try and help it
understand the control flow.
The loop is exited as soon as a target is found whose weight is greater
than or equal to a random value between 0 and the sum of all the weights
in the set of remaining targets in the loop. By definition, the last
target in the loop always satisfies this condition, so a target will
always be chosen, and hence `t` will never be `NULL` within the loop.
`t->data` will never be `NULL` by construction of the target list.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #1767
scan-build thinks that `data` could be leaked. It’s not, though; it’s
passed as the `user_data` to `g_dbus_connection_register_object()` along
with its free function.
Try and persuade scan-build that there’s no leak by annotating the
transfer.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #1767
scan-build was complaining that `dest_hostname` and `dest_protocol` were
used after being freed, which could potentially happen if the code is
built with `G_DISABLE_CHECKS`. This is a false positive, because the
state of types in the program should be the same regardless of whether
`G_DISABLE_CHECKS` is used.
However, the code did smell. If we are trying to free things and return
gracefully if the underlying socket address enumerator returns something
of the wrong type, why not free the rest of the function’s state, or
skip the invalid address and move on to the next one? Or if we are trying
to make an assertion, why bother freeing some temporary data at all?
This halfway house doesn’t make sense.
So turn the `g_return_val_if_fail()` into a full assertion.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #1767
After a lot of loop unwinding, during which I think it might have lost
its knowledge that `cache->buffer != NULL` (from a prior check on line
765), scan-build seems to think that there can be a `NULL` pointer
dereference of `cache->buffer` within `cache_magic_compare_to_data()`.
There can’t be. Add an assertion to try and help the analyser.
Upstreamed as
https://gitlab.freedesktop.org/xdg/xdgmime/-/merge_requests/38.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #1767
scan-build thinks that it’s possible for `read_netlink_messages()` to
return `FALSE` and an unset error (or `TRUE` and a set error), and this
belief causes it to emit warnings for code which calls
`read_netlink_messages()`.
That’s not possible, but the function is written in such a way that
following the control flow would be hard for a static analyser. It would
have to work out that `retval` and `local_error == NULL` are identical
on all control flow branches.
Avoid the need for such complex analysis by eliminating `retval` and
just using `local_error` throughout.
This introduces no functional changes to the code.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #1767
scan-build thinks that `term_arg` could be used uninitialised. I think
there isn’t a bug here because that use is protected by the
`found_terminal == NULL` check and early return. But perhaps that logic
is a bit too complex for static analysis, so add a default value for the
variable.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #1767
The previous approach was to return a length as a `gssize`, with
negative values indicating failure. That works fine, but causes a lot of
signed/unsigned comparisons or assignments.
Tidy the code up by splitting success from length, returning success as
a boolean, and length as a `size_t*` out argument. This introduces no
functional changes, but does tidy the code up and fix some compiler
integer warnings.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Basically various trivial instances of the following MSVC compiler
warning:
```
../gio/gio-tool-set.c(50): warning C4267: '=': conversion from 'size_t' to 'int', possible loss of data
```
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Looks like the original author mixed up where the link label and the
link URL goes. :p
Previously the link would point to "https://docs.gtk.org/gio/file
attributes", with a space and no file extension.
This will become confusing when we start tracking the owner of a
well-known-name sender, and it's redundant anyway. Instead, track the
1 bit of data that we actually need: whether it's a well-known name.
Strictly speaking this too is redundant, because it's syntactically
derivable from the sender, but only via extra string operations.
A subsequent commit will add a data structure to keep track of the
owner of a well-known-name sender, at which point this boolean will
be replaced by the presence or absence of that data structure.
Signed-off-by: Simon McVittie <smcv@collabora.com>
No functional change, just removing some nesting. The check for whether
signal_data->subscribers is empty changes from a conditional that tests
whether it is into an early-return if it isn't.
A subsequent commit will add additional conditions that make us consider
a SignalData to be still in use and therefore not eligible to be removed.
Signed-off-by: Simon McVittie <smcv@collabora.com>
No functional changes, except that the implicit ownership-transfer
for the rule field becomes explicit (the local variable is set to NULL
afterwards).
Signed-off-by: Simon McVittie <smcv@collabora.com>
Subsequent changes will need to access these data structures from
on_worker_message_received(). No functional change here, only moving
code around.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Using these is a bit more clearly correct than repeating them everywhere.
To avoid excessive diffstat in a branch for a bug fix, I'm not
immediately replacing all existing occurrences of the same literals with
these names.
The names of these constants are chosen to be consistent with libdbus,
despite using somewhat outdated terminology (D-Bus now uses the term
"well-known bus name" for what used to be called a service name,
reserving the word "service" to mean specifically the programs that
have .service files and participate in service activation).
Signed-off-by: Simon McVittie <smcv@collabora.com>
On GNOME/glib#3268 there was some concern about whether this would
allow an attacker to send signals and have them be matched to a
GDBusProxy in this situation, but it seems that was a false alarm.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This somewhat duplicates test_connection_signals(), but is easier to
extend to cover different scenarios.
Each scenario is tested three times: once with lower-level
GDBusConnection APIs, once with the higher-level GDBusProxy (which
cannot implement all of the subscription scenarios, so some message
counts are lower), and once with both (to check that delivery of the
same message to multiple destinations is handled appropriately).
Signed-off-by: Simon McVittie <smcv@collabora.com>
The recently added libmount-based unix mount monitoring may fail when the
device exceeds inotify limits. Let's fallback to the older implementation
in case of the `mnt_monitor_get_fd` function failure. This among others
fixes tracker-miners failures caused by seccomp rules.
Fixes: https://gitlab.gnome.org/GNOME/tracker-miners/-/issues/315
This is a partial revert and rework of commit
c79575362e, for the `gsettings` script
only (the other completion scripts are fine).
I blindly added quoting to everything shellcheck told me to, without
testing it properly.
As it turns out, the `$schemadir` argument to `gsettings` invocations
was deliberately not quoted, so that it would expand to zero arguments
if unset, and two arguments (`--schemadir /some/path`) if set earlier in
the command-being-completed.
Quoting it meant that it expanded to one argument (the empty string) if
unset, which caused the `gsettings` subcommands to fail, and hence any
further tab completion to fail.
Fix that as suggested on https://www.shellcheck.net/wiki/SC2086 by
turning `schemadir` into an array, which either has zero members if
unset, or two members if set.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
The copyright entries come from looking at `git log gio/completion/*`
and, in particular, `git log -- gio/gsettings-bash-completion.sh` (etc.)
as the files were moved after being originally written, and haven’t
really changed since.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #1415
As suggested by Ville Skyttä in
https://gitlab.gnome.org/GNOME/glib/-/merge_requests/4012#note_2084405,
make sure to invoke the copy of the command which is being completed
when asking for completions of a given subcommand.
This avoids accidentally invoking any old `gdbus`/`gresource`/etc.
binary which is hanging around in another part of `$PATH`.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
The copyright from `git log gio/inotify/meson.build` is now included in
the file header. The following commits are too trivial to be
copyrightable:
- d10be6102f
- 03e86d000f
- 1741fc2c6e
- 8733d172a3
The file was contributed while the `COPYING` file for GLib was
LGPL-2.1-or-later, so was previously implicitly licensed as that.
Let’s make that explicit.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #1415
The license and copyright are already stated in human-readable form in
these files, so this should be uncontroversial.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #1415
The `.flake8` file has a trivial version history, so the copyright is
straightforward from that.
`meson.build` has a more complex history, but the only significant
contributions were from Centricular. From `git log
gio/gdbus-2.0/codegen/meson.build`, the other (following) commits are
too trivial to be copyrightable:
- d10be6102f
- 30b25a6fd9
- 95fa229f34
- 631c3534b7
- 00d7568e4f
- 9734e4854e
- 65be80c3ed
- 66e4ba806a
- a1c78d63ef
- a73ca336aa
- 19353017a7
- b4231844a2
- 4cb945d780
- 4ce58df854
- e2433308c4
- 013980d839
Both files were contributed while the `COPYING` file for GLib was
LGPL-2.1-or-later, so both were previously implicitly licensed as that.
Let’s make that explicit.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #1415
The license and copyright are already stated in human-readable form in
these files, so this should be uncontroversial.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #1415
Using the same justification as in
https://gitlab.gnome.org/GNOME/dconf/-/merge_requests/81#note_2083220:
it’s hard to get this right, with error handling, in a way which is
understandable to people reading it, and which both bash and shellcheck
will be happy with.
On the assumption that none of the completions generated by any of these
utilities will include ‘problematic’ characters (ones which would cause
word splitting or globbing in bash), just ignore the shellcheck
warnings. Note that I have not actually closely verified that these
utilities can’t return ‘problematic’ characters.
This means we can enable shellcheck, with fatal warnings, for these
scripts, and hence catch future regressions.
If someone wants to improve the handling of globbing/word splitting in
some/all of these array assignments in future, the shellcheck disables
can be removed.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
This means that backslashes in the input (which is unlikely, but I guess
possible) won’t affect line splitting. Spotted by shellcheck.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Having them on the same line masks failure of the subcommand generating
the value being assigned. Spotted by shellcheck.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Because completion scripts are not executed directly, they don’t have a
shebang line, so shellcheck can’t be sure which shell syntax to use for
them. Help it out.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Rather than `strdup()`ing strings when passing them into
`_xdg_glob_list_append()`, `strdup()` them *inside* the function
instead.
This avoids a leak in the case that the list entry (tuple of `data` and
`mime_type`) already exists in the list.
This has been upstreamed as
https://gitlab.freedesktop.org/xdg/xdgmime/-/merge_requests/36.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Rather than iterating over the list twice: once to find the resource,
and once to re-find its link and delete it, just use
`g_list_delete_link()` to delete what was found.
This has the lovely side-effect of squashing a false positive from
scan-build, which thought there was a use-after-free of `resource` in
the caller, due to `g_resource_unref()` being called on it here.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #1767
There were a couple of functions in `GDBusConnection` which take a
`user_data` argument, but which then leak it if they error out early.
A true positive spotted by scan-build!
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #1767
There were some error paths where it wasn’t set, returning an
uninitialised value to the caller.
Spotted by scan-build.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #1767
It might not actually be needed (I haven’t checked if the default is
correct), but it certainly does no harm and makes things explicit.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Just like we already do in `GSocket`.
This is necessary when using `g_subprocess_communicate()` with a
subprocess which calls `close()` on its stdin FD at some point. `cat`
does this just before exiting, for example.
This causes a `write()` to the stdin pipe in the parent process to fail
with `EPIPE` and `SIGPIPE`. The condition is not detectable in advance,
because the `close()` call could happen after the `GMainContext` has
dispatched a `g_subprocess_communicate()` callback.
If it weren’t for the `SIGPIPE`,`g_subprocess_communicate()` would be
able to handle the `EPIPE` just fine. `SIGPIPE` seems like a default
error handling path which was useful in 1980 for writing pipe-heavy
command line apps, but which is more of a broken stair for writing
larger modern apps which have more than one data flow path.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Fixes: #3310
With the shell in nounset mode, an error is emitted on referencing
`schemadir` as it is not initialized in all code paths.
Initialize to an empty string to fix.
Signed-off-by: Ville Skyttä <ville.skytta@iki.fi>
The source language of GLib is technically en-US, so we should
consistently use en-US spellings.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3269
The python interpreter found by `/usr/bin/env python3` is not
necessarily the same installation as the one that's found by meson's
`pymod.find_installation('python')`. This means that even though meson
is checking that the python installation it found includes the
'packaging' module, the scripts might not have access to that module
when run.
For distribution packaging, it's usually desirable to have python script
interpreters be fully specified paths, rather than use `/usr/bin/env`,
to ensure the scripts run using the expected python installation (i.e.
the one where the python 'packaging' dependency is installed).
The easiest way to fix this is to set the script interpreter to the
`full_path()` of the python interpreter found by meson. The specific
python interpreter that will be used can be selected through the use of
a meson machine file by overriding the "python" program. Many
distributions already have this set up using meson packaging helpers.
There are a lot of links to the description of I/O priority in the GIO
docs, and they’re all currently broken since the docs build was ported
to gi-docgen.
Use a simple find and replace (see below) to fix them. This doesn’t port
any of the surrounding docs to gi-docgen format, but should still
improve things overall.
```sh
git search-replace --fix '\[I/O priority\]\[io-priority\]///[I/O priority](iface.AsyncResult.html#io-priority)'
```
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3250
g_file_copy_async() and g_file_move_async() are written in a way that is
not bindable with gobject-introspection. The progress callback data can
be freed once the async callback has been called, which is convenient
for C, but in language bindings the progress callback closure is
currently just leaked.
There is no scope annotation that fits how the progress callback should
be treated:
- (scope call) is correct for the sync versions of the functions, but
incorrect for the async functions; the progress callback is called
after the async functions return.
- (scope notified) is incorrect because there is no GDestroyNotify
parameter, meaning the callback will always leak.
- (scope async) is incorrect because the callback is called more than
once.
- (scope forever) is incorrect because the callback closure could be
freed after the async callback runs.
This adds g_file_copy_async_with_closures() and
g_file_move_async_with_closures() for the benefit of language bindings.
See: GNOME/gjs#590
This is an introspection-friendly version of g_settings_bind_with_mapping.
Having two callbacks that share the same user data is not supported by
girepository, so the existing function is not introspectable.
Closes: #564
These consistently fail on scheduled CI runs, which is not helping our
ability to catch Hurd regressions.
For example, https://gitlab.gnome.org/GNOME/glib/-/jobs/3709402
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
See: #3148
The gdbus-example-objectmanager visibility header was being re-created
on reconfigure, causing a needless rebuild of gdbus tests that were
using the visibility header.
All other invocations of gen_visibility_macros are via custom_target.
If we don't do this, the --help text is formatted as though the option
did not expect an argument.
IDENTIFIER is a new translated string, but it is developer-oriented,
so a missing translation is not particularly bad. COMMAND is already
present in translations.
Signed-off-by: Simon McVittie <smcv@collabora.com>
If we don't do this, the --help text is formatted as though the option
did not expect an argument.
This introduces a new translated string, but it is developer-oriented,
so a missing translation is not particularly bad.
Signed-off-by: Simon McVittie <smcv@collabora.com>
The ref held by `data->task` may be the last one on the `GTask`. The
`GTask` stores `attempt->data` as its task data, and so when the `GTask`
is finalised, `attempt->data` is too. `connection_attempt_remove()`
needs to access `attempt->data`, so must be called before the
`g_object_unref()` in this situation.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Fixes: #3266
Currently, the `stop_func` is executed on an extra thread, and the
`g_context_specific_group_remove` function returns before the `stop_func`
finishes. It may happen that the `stop_func` is never executed if the
program terminates soon after calling it. Let's wait until the `stop_func`
is done.
Fixes: https://gitlab.gnome.org/GNOME/glib/-/issues/3258
This should clarify things a little for users of language bindings, who
don’t directly use `.pc` files.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
This creates `GioUnix`, `GioWin32`, `GLibUnix` and `GLibWin32`. These
bodies of documentation are in addition to the main, platform agnostic,
documentation for both libraries.
This commit necessarily includes various mechanical changes to update
the repository namespace used in various existing documentation links to
platform specific APIs.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3037
There was no obvious logical need to list the `GAppInfo` subclass
sources separately in the build. It makes more sense to add them to the
platform-specific source lists, since they are platform specific.
This will be used in an upcoming commit which generates
platform-specific GIR files, so needs the full platform-specific lists
of sources.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3037
`GFileDescriptorBased` is in `gio-unix-2.0` rather than `gio-2.0`, so
its types shouldn’t be declared in a header belonging to the latter.
This hasn’t been a problem previously because C is fine with that. But
upcoming commits are going to split the introspection scanning for
`gio-2.0` and `gio-unix-2.0`, and the introspection scanner is a little
more picky about declarations not being spread all over the place.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3037
The symbols still have to be exported from the library (since they’re
called from unit tests), but there was never any reason for them to be
in a public header.
This means they now disappear from `Gio-2.0.gir`.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3231
This property is supposed to be used by authors of applications that use GAppliaction to output the version by --version flag or otherwise if a version is needed.
Closes#3198
Signed-off-by: Maxim Moskalets <Maxim.Moskalets@kaspersky.com>
This is another way to get the file system type from `statvfs()`, newly
added in glibc 2.39
(https://lwn.net/ml/libc-alpha/38790850.J2Yia2DhmK@pinacolada/).
This hasn’t been tested with glibc 2.39 as I don’t have it, but the
change seems fairly straightforward.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
It’s not suitable to use to check if your own code has already called
`g_task_return_*()`, as it doesn’t directly correlate to that.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
If we're writing the body to standard output, we cannot know what the
filename of the corresponding header is going to be, but it seems
vanishingly unlikely that it will be either `stdout.h` (which we would
traditionally have generated) or `-.h` (which we would have generated
since !3886).
This makes some of the output snippets sufficiently short that black(1)
requires that they are folded into a single line.
Signed-off-by: Simon McVittie <smcv@collabora.com>
In command-line tools, ordinary filenames normally do not have
special-cased meanings, so commit 3ef742eb "Don't skip dbus-codegen tests
on Win32" was a command-line API break: in the unlikely event that a
user wanted to write to a file named exactly `stdout`, this would have
been an incompatible change.
There is a conventional pseudo-filename to represent standard output,
which is `-` (for example `cat -` is a no-op filter). Adding support
for this is technically also a command-line API break (in the very
unlikely event that a user wants to write to a file named exactly `-`,
they would now have to write it as `./-`), but filenames starting with
a dash often require special treatment anyway, so this probably will not
come as a surprise to anyone.
When the output filename is `-` we don't want to use `#ifdef _____` as
a header guard, so special-case it as `__STDOUT__` as before.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Memory was leaking when allocating it inside libelf and losing the pointer to it (it was an automatic variable) when returning NULL from the get_elf function in some cases
Closes#3242
Signed-off-by: Maxim Moskalets <Maxim.Moskalets@kaspersky.com>
This reverts commit fbdc9a2d03.
It was not submitted through a merge request and broke CI. Reverting it
immediately to unbreak CI and hence the rest of the development
pipeline. The changes can be re-submitted as a merge request so they’re
properly tested in CI before being merged.
See https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3857#note_1994336
The previous commit enabled the `/run/mount/utab` monitoring. The problem
is that the `mount-changed` signal can be emitted twice for one mount. One
for the `/proc/mounts` file change and another one for the `/run/media/utab`
file change. This is still not ideal because e.g. the `GMount` objects for
mounts with the `x-gvfs-hide` option are added and immediately removed.
Let's enable the `mnt_monitor_veil_kernel` option to avoid this.
Related: https://github.com/util-linux/util-linux/pull/2725
The `GUnixMountMonitor` object implements monitoring on its own currently.
Only the `/proc/mounts` file changes are monitored. It is not aware of the
`/run/mount/utab` file changes. This file contains the userspace mount
options (e.g. `x-gvfs-notrash`, `x-gvfs-hide`) among others. There is a
problem when `/sbin/mount.<type>` (e.g. `mount.nfs`) helper programs are
used. In that case, the `/run/mount/utab` file is updated later than the
`/proc/mounts` file and thus the `GUnixMountMonitor` clients (e.g.
`gvfs-udisks2-volume-monitor`, `gvfsd-trash`) don't see the userspace
options until the next `mount-changed` signal. Let's use the `libmnt_monitor`
API for monitoring instead and emit the `mount-changed` signal also when the
`/run/mount/utab` file is changed.
Related: https://issues.redhat.com/browse/RHEL-14607
Related: https://github.com/util-linux/util-linux/pull/2607
This fixes a race condition which frequently caused the
`memory-monitor-dbus.py` test to fail.
The registration of the `LowMemoryMonitor` object on the bus, and the
`GMemoryMonitorDBus`’s connection to the warning signal raced, such that
it was possible for the mock `LowMemoryMonitor` to emit a warning signal
before the `GMemoryMonitorDBus` proxy was listening, and hence the proxy
would never see the signal.
Fix this by explicitly synchronising the two before proceeding to the
tests.
Make the same changes in the `memory-monitor-portal.py` test too, even
though that one was not failing. This should remove the need for a 2s
wait on every test run.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Fixes: #2887
Otherwise the test can go on to wait for a signal from the service
before it’s actually finished starting up.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #2887
Rather than sleeping and blocking everything, use a timeout source on
the main context so that inputs can continue to be handled while waiting
for a timeout.
This introduces no functional changes to the test.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #2887
It should be doing already (or the tests would never work), but make it
clearer in the code that the same `GMainContext` is being iterated as is
being woken up in the rest of the test.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #2887
When linking static libraries, multiple resources is an error unless
handled in a special way. glib and gobject do not have this problem,
as they already only include resources when building a shared lib.
I ran Bustle/dbus-monitor on the session bus while running the full GLib
test suite, and noticed that these tests were causing `Launched` signal
emissions on the main session bus. That suggested they weren’t isolated
properly, which at best causes noise on the bus and at worst could cause
spurious test failures.
Fix that by running those tests in a `GTestDBus` environment, as some of
the other appinfo tests already are.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
As seen in [CI](https://gitlab.gnome.org/GNOME/glib/-/jobs/3436216):
```
==13767== 144 (40 direct, 104 indirect) bytes in 1 blocks are definitely lost in loss record 528 of 562
==13767== at 0x4A18B2C: g_type_create_instance (gtype.c:1928)
==13767== by 0x49F92FF: g_object_new_internal (gobject.c:2235)
==13767== by 0x49FA247: g_object_new_valist (gobject.c:2574)
==13767== by 0x49F8D81: g_object_new (gobject.c:2047)
==13767== by 0x4AE2337: g_inet_socket_address_new (ginetsocketaddress.c:387)
==13767== by 0x4B1DB94: g_socket_address_new_from_native (gsocketaddress.c:230)
==13767== by 0x4B16CC2: g_socket_get_local_address (gsocket.c:2071)
==13767== by 0x40E102: test_receive_bytes_from (socket.c:2469)
==13767== by 0x4901E78: test_case_run (gtestutils.c:2974)
==13767== by 0x49022B2: g_test_run_suite_internal (gtestutils.c:3069)
==13767== by 0x490241A: g_test_run_suite_internal (gtestutils.c:3088)
==13767== by 0x4902690: g_test_run_suite (gtestutils.c:3168)
==13767== by 0x4900C8F: g_test_run (gtestutils.c:2275)
==13767== by 0x40EE8A: main (socket.c:2614)
```
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3220
There are several reasons why we might not be able to do the test setup
for --external-data: non-Linux platform, missing ld or objcopy,
objcopy doesn't support --add-symbol, or the CPU family is MIPS
(on which cc -r does not necessarily emit the specific MIPS ABI flavour
that we are targeting, for example different functionality levels or
different NaN encodings).
If we can't link in the test data, then obviously this test is not going
to pass. It was already skipped on non-Linux, but not on platforms that
hit one of the other reasons for the test setup to fail.
In particular, this test failed on Debian mips64el since commit 81059169,
which stopped linking the necessary resource on MIPS platforms, but
continued to assert that the resource is present at runtime.
Fixes: 81059169 "GIO/tests: skip test_resources_binary on MIPS platform"
Resolves: https://gitlab.gnome.org/GNOME/glib/-/issues/3226
Signed-off-by: Simon McVittie <smcv@debian.org>
The title of an interface can be arbitrarily long, considering that
reverse DNS namespaces can be pretty complex. Instead of using the whole
interface name, we can use the name without the prefix.
Generating gir and typelib files has inter-dependencies that may depend
on other elements.
For example, glib requires gobject and gdump generated files require
gmodule, so we've a cyclic dependency because gmodule requires gobject,
that requires glib.
To prevent this, let's just generate the introspection files at once in
a different meson file so that we don't have to deal with this.
As per this we could even revert commit fa37ab6d0 since gio is now
compiled before the gir files.
The code for stripping the query and fragment from file:// URIs was
wrong, as it would not properly strip a query if there was a fragment.
Fortunately, that code was actually useless, as the "stripped URI" was
passed to g_filename_from_uri() that does proper stripping itself.
So simply drop this extra unnecessary stripping logic from GLocalVFS's
get_file_for_uri() and let g_filename_from_uri() do all the work.
The same struct was reused across multiple tests, but without a shared
way of freeing its members. Refactor to add one.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
