Previously, the code validated that child objects have a path with the
object manager strictly as a prefix. That doesn’t work in the case where
the object manager’s path is `/`. This case is not recommended, but is
supported.
If the object manager’s path is `/`, validate that child objects’ paths
are not equal to it. If they are equal to it, warn the user rather than
emitting a critical warning, since we can’t expect any users who’ve not
been compliant with the spec to instantly rework their D-Bus APIs.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2500
0.2 was just tagged, which includes a commit from 2018 that fixes a
meson warning which caused the project to fail to build on Windows with
--fatal-meson-warnings enabled.
Emit this when we're about to spawn or DBus activate a GAppInfo. This
allows lauchers to keep the appinfo associated with a startup id.
We use a GVariant to allow for future exansion of the supplied data.
When using g_desktop_app_info_launch_uris_as_manager the "launched"
signal allows to map a desktop-startup-id to a GAppInfo. Make this
possible for DBus activation too.
Since we don't have a PID there we pass a 0. Update the signal
description accordingly.
These should be implemented by loadable IO module libraries, but are not
callable in GLib itself.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2498
This is a partial revert of commit
f378352051, as the previous commits have
silenced the AddressSanitizer warnings for `GContentType`.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2310
These just wrap the `__lsan_enable()` and `__lsan_disable()` functions
from the AddressSanitizer client API. They’re useful in situations where
the intended-to-be-leaked memory is being allocated in third-party code,
such as xdgmime. We can’t patch that code to call `g_ignore_leak()`.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2310
The function pointer casts silence the compiler and allow the code to
build (and even run in the typical case). However, when building with
control flow integrity checks, the runtime (rightfully) complains about
calling a function via a mismatched function pointer type.
In order to make xdgmime properly relocatable so that unit tests can use
it without it reading and modifying the user’s actual xdgmime files, and
without the need to call setenv() (and get tied up with thread safety
problems), add a xdg_mime_set_dirs() method to allow the dirs to be
overridden. They will still default to the values of $XDG_DATA_HOME and
$XDG_DATA_DIRS.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Allocate an empty cache object, check cache objects for being empty
before using them.
Otherwise the code will re-read cache every 5 seconds, as NULL cache
does not trigger the code that stores mtime, which makes the cache
file appear modified/unloaded permanently.
https://bugzilla.gnome.org/show_bug.cgi?id=735696
Since returning exactly one match has special significance, don't
give up matching before we've found at least 2 types. Also, make
sure that we don't return the same mime type more than once.
Bug 541236.
If an `InterfacesRemoved` signal is received for an object which doesn’t
exist in the local map of interfaces, don’t emit a warning.
This seems to happen in the real world (see #2401). Without a trace of
the D-Bus traffic it’s not possible to know exactly what situation is
causing this, but it seems possible that the peer could disappear and
its `notify::name-owner` signal could be processed before its
`InterfacesRemoved` signal, or something similar.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2401
Provide built DLLs as Gitlab-CI artifacts
To be clear, these are for testing purposes, and are not
supported releases.
See merge request GNOME/glib!2261
g_get_user_database_entry() capitalises the first letter of pw_name
with g_ascii_toupper (pw->pw_name[0]).
However, the manpage for getpwnam() and getpwuid() says the result of
those calls "may point to a static area". GLib is then trying to edit
static memory which belongs to a shared library, so segfaults.
The reentrant variants of the above calls are supposed to fill the user
buffer supplied to them, however Michael Catanzaro also found a bug in
systemd where the data is not copied to the user buffer and still points
to static memory, resulting in the same sort of segfault. See:
https://github.com/systemd/systemd/issues/20679
Solve both these cases in GLib by copying pw_name off to a temporary
variable, set uppercase on that variable, and use the variable to join
into the desired string. Free the variable after it is no longer needed.
Signed-off-by: Jamie Bainbridge <jamie.bainbridge@gmail.com>
Relax assertion about opened registry key as it may have been removed
in the meantime between enumeration and when opening, or (more likely)
we may not have the required permissions to open the some enumerated
keys (i.e. RegOpenKeyExW fails and returns ERROR_ACCESS_DENIED).
Fixes https://gitlab.com/inkscape/inbox/-/issues/5669
It fixes a race. g_source_attach() had the following check to ensure a
loop blocked on poll() would wakeup.
if (do_wakeup && context->owner && context->owner != G_THREAD_SELF)
g_wakeup_signal (context->wakeup);
However it doesn't contemplate an implementation where poll()ing is a
non-blocking operation that will be scheduled while the thread is
released to perform other tasks. This scenario opens up several
different possibilities where the condition would fail to hold true. I
experienced two of such races.
The first race pertains to a mono-threaded application. Do keep in mind
that integrating GLib to a foreign event loop will make GLib act as a
slave in the new event loop. When you post a new work unit to execute in
the thread managed by the foreign event loop, you don't use
g_main_context_invoke(). In fact the only reason to integrate
GMainContext in a foreign event loop is to make the two of them
communicate. So from time to time, the foreign event loop will execute
callbacks that manipulate the GMainContext loop. An illustration
follows.
// in this callback we translate an event from the foreign event loop
// to an event in the GMainContext event loop (that runs in the same
// thread)
static void my_event_loop_callback(void* data)
{
GMainContext* ctx = /* ... */;
// ...
g_source_attach(source, ctx);
}
int main()
{
// ...
my_event_loop_invoke(my_event_loop_callback, data);
// ...
// this function has all mechanisms in place to run the foreign
// event loop and the hooks to call
// g_main_context_{prepare,query,check,dispatch}
my_event_loop_run();
}
In this case, you would have the following series of calls:
1. g_main_context_prepare()
2. g_main_context_query()
3. A callback to my_event_loop is registered when any fd on the set is
ready or the timeout is reached.
4. The thread is released to perform other tasks.
5. One of the tasks executed wishes to communicate with my_event_loop
and enters my_event_loop_callback.
6. g_source_attach() is called.
7. g_source_attach() detects do_wakeup=TRUE, context->owner != NULL, and
context->owner == G_THREAD_SELF so g_wakeup_signal() is skipped.
8. None of the fds on the GLib poll() set becomes ready nor the GLib
timeout expires. The my_event_loop callback that would call
g_main_context_check() is never executed. Deadlock.
A shallow analysis will fail to detect the race here. The explanation
seems to showcase a scenario that will deterministically fail with a
deadlock every time. However do keep in mind that my_event_loop_callback
could be invoked before or after g_main_context_prepare(). There is an
_event_ race here. Furthermore, some GLib libraries such as GDBus will
initialize objects from extra threads (GAsyncInitable interface) and
invoke the result on the original thread when ready (g_source_attach()
will eventually be called). Now you have scenarios closer to standard
race examples.
The other scenario where a race would manifest happens in a
multi-threaded application that has a concurrency design similar to the
actor model. No actor executes in two threads simultaneously, but it's
not guaranteed that it'll always wake-up in the same thread. It'd
perform steps 1-4 just as in the previous example, but before thread
control is returned to the pool, it'd call g_main_context_release(). Now
g_source_attach() would skip g_wakeup_signal() for a different reason:
7. g_source_attach() detects do_wakeup=TRUE, context->owner == NULL so
g_wakeup_signal() is skipped.
8. Same as before.
Certainly there are other concurrency designs where this optimization
would cause a deadlock, but all of them have origin in the same place:
the optimization assumes the poll() implementation is a blocking
operation and the thread will never be released to perform other tasks
(possibly involving GLib calls) while result is not ready. They share
not only the same problem, but also the same solution: do not make
assumptions and just call g_wakeup_signal().
This patch implements this solution by introducing the
G_MAIN_CONTEXT_FLAGS_OWNERLESS_POLLING flag. This flag will force a call
to g_wakeup_signal() and fix the race on foreign event loops. The reason
to prevent changing this option after creation is to avoid other races
that would lead to event loss. Construction is the only proper time to
set this option.
The implementation design means we do not change **any** semantics for
current working code. If you don't set the new flag, the code won't
enter in different branches and current behavior won't be affected. The
patch is small and easy to follow too.
