GCancellable is meant to be used in multi-thread operations but all the
cancellable instances were sharing a single mutex to synchronize them
which can be less optimal when many instances are in place.
Especially when we're doing a lock/unlock dances that may leave another
thread to take the control of a critical section in an unexpected way.
This in fact was leading to some races in GCancellableSources causing
leaks because we were assuming that the "cancelled" callback was always
called before our dispose implementation.
As per this, use per-instance mutexes.
The lock is also now used only to protect the calls that may interact
with cancelled state or that depends on that, as per this we can just
reduce it to the cancel and reset case, other than to the connect one to
prevent the race that we could have when connecting to a cancellable
that is reset from another thread.
We don't really need to release the locks during callbacks now as they
are per instance, and there's really no function that we allowed to call
during a ::cancelled signal callback that may require an unlocked state.
This could been done in case with a recursive lock, that is easy enough
to implement but not really needed for this case.
Fixes: #2309, #2313
This latent bug wasn’t triggered until commit 3f30ec86c (or its
cherry-pick onto `glib-2-80`, 747e3af99, which was first released in
2.80.1).
That change means that `g_menu_exporter_free()` is now called on the
registration failure path by `g_dbus_connection_register_object()`
before it returns. The caller then tries to call `g_slice_free()` on the
exporter again. The call to `g_menu_exporter_free()` tries to
dereference/free members of the exporter which it expects to be
initialised — but because this is happening in an error handling path,
they are not initialised.
If it were to get any further, the `g_slice_free()` would then be a
double-free on the exporter allocation.
Fix that by making `g_menu_exporter_free()` robust to some of the
exporter members being `NULL`, and moving some of the initialisation
code higher in `g_dbus_connection_export_menu_model()`, and removing the
duplicate free code on the error handling path.
This includes a unit test.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Fixes: #3366
This solves problems with validating untrusted inputs from D-Bus, where
invalid numbers of added and removed menu entries, and positions, could
be specified.
Original patch from
https://bugzilla.gnome.org/show_bug.cgi?id=728733#c7, tweaked by Philip
Withnall to add a few code comments and make
`G_MENU_EXPORTER_MAX_SECTION_SIZE` public so callers can check their
inputs against it if they want. Also tweaked to use `g_warning()` instead
of the nonexistent `g_dbus_warning()`.
Fixes: #861
Various tests have leaks where it isn't clear whether the data is
intentionally not freed, or leaked due to a bug. If we mark these
tests as TODO, we can skip them under AddressSanitizer and get the
rest to pass, giving us a baseline from which to avoid regressions.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Previously, we waited an arbitrary 100ms or 200ms and then asserted
that the events had happened, but that might fail if the machine is
slow or heavily loaded.
We still wait for an arbitrary time for negative tests (asserting
that no more signals are received) because we don't have any way
to do better here.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=884661https://bugzilla.gnome.org/show_bug.cgi?id=791744
It's unnecessary, and only adds visual noise; we have been fairly
inconsistent in the past, but the semi-colon-less version clearly
dominates in the code base.
https://bugzilla.gnome.org/show_bug.cgi?id=669355
Very many testcases, some GLib tools (resource compiler, etc) and
GApplication were calling g_type_init().
Remove those uses, as they are no longer required.
https://bugzilla.gnome.org/show_bug.cgi?id=686161
GDBusConnection now dispatches GDestroyNotify calls back to the
mainloop. Adding an idle to the mainloop is O(n) in the number of idles
already there. We therefore need to periodically empty the mainloop to
avoid quadratic behaviour with a very large 'n'.
Sometimes randa and randb end up having the same state, causing them to
return the same stream of 'random numbers'. This is a problem for the
testcase that is looping to find unequal menus.
If we find ourselves in this state, throw one of the random generators
away and recreate it so we have a better chance of getting some unequal
menus.
Give it the same treatment as the exporter for GActionGroup just got.
There is a wart here: the exporter attempt to re-enter GDBusConnection
when it is freed in order to cancel outstanding name watches.
GDBusConnection holds its own lock while calling the destroy notify, so
the attempt at reentrancy results in a deadlock.
We have a workaround to deal with that for now...
Create a 'mirror' model of the proxy for the testcase. In addition to
testing that the proxy model emits the proper signals this also keeps
the proxy alive (by holding references to it from the mirror).
The previous code would create the submenu proxies and destroy them
right away (from the recursive step in the equality comparison
functions). This means that the subscription would go out over D-Bus
and the proxy would be destroyed before it returned. Keeping the model
alive allows it to be actually updated.
Each test needs to remove the sources that it attaches
to the default main context, or else things will work
fine in isolation, but go bad in a full test run.
There are no public 'exporter' objects, so don't allude to them
in the function names. At the same time, we want to make it clear
that these functions are D-Bus specific.
The new APIs are
g_action_group_dbus_export_start
g_action_group_dbus_export_query
g_action_group_dbus_export_stop
g_menu_model_dbus_export_start
g_menu_model_dbus_export_query
g_menu_model_dbus_export_stop
