Some CI platforms invoke these tests with euid != 0 but with
capabilities. Detect whether we have Linux CAP_DAC_OVERRIDE or other
OSs' equivalents, and skip tests that rely on DAC permissions being
denied if we do have that privilege.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Fixes: https://gitlab.gnome.org/GNOME/glib/issues/2027
Fixes: https://gitlab.gnome.org/GNOME/glib/issues/2028
Some CI platforms invoke tests as euid != 0, but with capabilities that
include CAP_SYS_RESOURCE and/or CAP_SYS_ADMIN. If we detect this,
we can't test what happens if our RLIMIT_NPROC is too low to create a
thread, because RLIMIT_NPROC is bypassed in these cases.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Fixes: https://gitlab.gnome.org/GNOME/glib/issues/2029
The relevant parts of the generated example documentation are already
`xi:include`d into the `migrating-gdbus.xml` page, so are turned into
HTML there. Installing them separately means they also get installed
into `/usr/share/gtk-doc/html/gdbus-object-manager-example/`, which
seems redundant.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
This does not have any behaviour changes but is cleaner. The mutex is
only unlocked now after all operations on the context are done and right
before freeing the mutex and the context itself.
Instead of destroying sources directly while freeing the context, and
potentially freeing them if this was the last reference to them, collect
new references of all sources in a separate list before and at the same
time invalidate their context so that they can't access it anymore. Only
once all sources have their context invalidated, destroy them while
still keeping a reference to them. Once all sources are destroyed we get
rid of the additional references and free them if nothing else keeps a
reference to them anymore.
This fixes a regression introduced by 26056558be in 2012.
The previous code that invalidated the context of each source and then
destroyed it before going to the next source without keeping an
additional reference caused memory leaks or memory corruption depending
on the order of the sources in the sources lists.
If a source was destroyed it might happen that this was the last
reference to this source, and it would then be freed. This would cause
the finalize function to be called, which might destroy and unref
another source and potentially free it. This other source would then
either
- go through the normal free logic and change the intern linked list
between the sources, while other sources that are unreffed as part of
the main context freeing would not. As such the list would be in an
inconsistent state and we might dereference freed memory.
- go through the normal destroy and free logic but because the context
pointer was already invalidated it would simply mark the source as
destroyed without actually removing it from the context. This would
then cause a memory leak because the reference owned by the context is
not freed.
Fixes https://github.com/gtk-rs/glib/issues/583 while still keeping
https://bugzilla.gnome.org/show_bug.cgi?id=661767 fixes.
We first have to ref the next source and then unref the previous one.
This might be the last reference to the previous source, and freeing the
previous source might unref and free the next one which would then leave
use with a dangling pointer here.
Fixes https://gitlab.gnome.org/GNOME/glib/issues/2031
It was used for running tests when we built with autotools, but is no
longer used in the Meson build system. If we need something similar in
future, it should be done by adding internal API to override the
directory on a per-call basis, rather than loading a path from a shared
global table every time.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Helps: #1919
There were a couple of custom paths which could end up being relative,
rather than absolute, due to not properly prefixing them with
`get_option('prefix')`.
The use of `join_paths()` here correctly drops all path components
before the final absolute path in the list of arguments. So if someone
configures GLib with an absolute path for `gio_module_dir`, that will be
used unprefixed; but if someone configures with a relative path, it will
be prefixed by `get_option('prefix)`.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Fixes: #1919
Replacing file destination will also remove a symlink in case the user has moved the
real file to another location. Fix this by removing G_FILE_CREATE_REPLACE_DESTINATION flag.
See also: https://gitlab.gnome.org/GNOME/epiphany/issues/198
The loops should continue iterating if the timeout is non-zero and we're
still waiting for the updated value. Otherwise, if things break, we'll
be waiting until we receive a value that never arrives.
If podman is used, as is usually the case on a Fedora Workstation
installation, make sure not to use "sudo" as that's not needed.
Also ask podman's backend (buildah) to create Docker compatible images
through an environment variable rather than a command-line argument.
See https://gitlab.gnome.org/GNOME/glib/merge_requests/1255
"gio info" output doesn't contain any information about mount points, but
that information can be useful when debugging issues in facilities that
depend on knowing about mount points, such as the trash API.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Co-authored-by: Ondrej Holy <oholy@redhat.com>
Documentation says that g_file_peek_path() returns exactly the same
what g_file_get_path(), but this is not true. Apart from that the code
segfaults for some uris (e.g. for "trash:///"), it returns target-uri
for trash and recent schemes. This is unexpected and can lead to various
issues among others because the target-uri paths are not automatically
translated back to GDaemonFile as it is done with gvfsd-fuse paths.
g_file_get_path() returns NULL for trash and recent schemes, because
fuse paths are not provided for those schemes. So g_file_peek_path()
should return NULL as well. It is up to the concrete application to
use target-uri when appropriate.
This change was made as a part of commit 4808a957, however, neither
the commit message, neither the corresponding bug doesn't mention this
crucial change and doesn't give any clear reasoning. So let's revert
this.
