Ensure we don't do an user-after-free access, as reported by ASAN:
==3704==ERROR: AddressSanitizer: stack-use-after-return on address
0x70a58f8631c0 at pc 0x000000405144 bp 0x7fffff62c7a0 sp 0x7fffff62c798
READ of size 4 at 0x70a58f8631c0 thread T0
#0 0x405143 in on_object_unregistered ../../GNOME/glib/gio/tests/gdbus-export.c:597
#1 0x70a592e858d8 in call_destroy_notify_data_in_idle ../../GNOME/glib/gio/gdbusconnection.c:244
#2 0x70a5940016a4 in g_idle_dispatch ../../GNOME/glib/glib/gmain.c:6221
#3 0x70a59401095b in g_main_dispatch ../../GNOME/glib/glib/gmain.c:3348
#4 0x70a59401095b in g_main_context_dispatch_unlocked ../../GNOME/glib/glib/gmain.c:4197
#5 0x70a59401ba17 in g_main_context_iterate_unlocked ../../GNOME/glib/glib/gmain.c:4262
#6 0x70a59401cc73 in g_main_context_iteration ../../GNOME/glib/glib/gmain.c:4327
#7 0x405658 in test_threaded_unregistration_iteration ../../GNOME/glib/gio/tests/gdbus-export.c:1878
#8 0x405658 in test_threaded_unregistration ../../GNOME/glib/gio/tests/gdbus-export.c:1952
#9 0x70a5940dfb04 in test_case_run ../../GNOME/glib/glib/gtestutils.c:2988
#10 0x70a5940dfb04 in g_test_run_suite_internal ../../GNOME/glib/glib/gtestutils.c:3090
#11 0x70a5940df893 in g_test_run_suite_internal ../../GNOME/glib/glib/gtestutils.c:3109
#12 0x70a5940df893 in g_test_run_suite_internal ../../GNOME/glib/glib/gtestutils.c:3109
#13 0x70a5940e0bc9 in g_test_run_suite ../../GNOME/glib/glib/gtestutils.c:3189
#14 0x70a5940e0d1f in g_test_run ../../GNOME/glib/glib/gtestutils.c:2275
#15 0x40eb72 in session_bus_run ../../GNOME/glib/gio/tests/gdbus-sessionbus.c:69
#16 0x403a2c in main ../../GNOME/glib/gio/tests/gdbus-export.c:1990
#17 0x70a591d9f149 in __libc_start_call_main (/lib64/libc.so.6+0x28149) (BuildId: 0d710e9d9dc10c500b8119c85da75004183618e2)
#18 0x70a591d9f20a in __libc_start_main_impl (/lib64/libc.so.6+0x2820a) (BuildId: 0d710e9d9dc10c500b8119c85da75004183618e2)
#19 0x403b44 in _start (/tmp/_build/gio/tests/gdbus-export+0x403b44) (BuildId: f6312e919c3d94e4c49270b0dfc5c870e1ba550b)
Address 0x70a58f8631c0 is located in stack of thread T0 at offset 192 in frame
#0 0x40525f in test_threaded_unregistration ../../GNOME/glib/gio/tests/gdbus-export.c:1936
This frame has 7 object(s):
[32, 40) 'local_error' (line 1835)
[64, 72) 'unregister_thread' (line 1836)
[96, 104) 'value' (line 1838)
[128, 136) 'value_str' (line 1839)
[160, 168) 'call_result' (line 1840)
[192, 204) 'object_registration_data' (line 1834) <== Memory access at offset 192 is inside this variable
[224, 240) 'data' (line 1833)
Move the shebang line from the full Python path of the build
machine to the first Python on the path during runtime. Set
the shebang in the main meson.build file so that it can be
overridden in one place if needed.
Fixes: #3331
Prevent to access to a disposed gsource in the GCancellable cancelled
signal callback.
Due to the fact that the signal is called in the same thread in which
the cancellable get cancelled, we may receive the callback just after
the GSource has been disposed or during its disposal.
To prevent this, let's pass to the signal a pointer to the source itself
and nullify atomically the first time we're calling a callback or
disposing it.
In case the dispose function wins the race, then the callback will just
do nothing, while the disposal will continue as expected.
In case the callback wins the race, during the concurrent disposal we'll
just wait for the callback to be completed, before returning the disposal
itself that will likely lead to freeing the GSource.
Closes: #3448
It finally happened: someone managed to keep a process alive long
enough, and using a single `GDBusConnection`, to overflow the
`last_serial` counter in the connection and send an invalid message with
serial of zero (which is disallowed by the D-Bus specification).
Avoid that happening in future by skipping serials of zero on overflow,
and wrapping straight back around to 1.
This looks a little more confusing than it is, because `last_serial` is
pre-incremented on use, so to skip zero, we explicitly set it to zero.
This is exactly what happens when the `GDBusConnection` is initialised
anyway.
I can’t think of a way to add a unit test for this — there is no way to
affect the value of `last_serial` except by sending messages (each one
increments it), and in order to get it to overflow by sending messages
at 1kHz, the test would have to run for 49 days.
Instead, I tested this manually by temporarily modifying
`GDBusConnection` to initialise `last_serial` to `G_MAXUINT32 - 3`, then
checked that the unit tests all still passed, and that the overflow code
was being executed.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Fixes: #3592
The registry backend uses a thread to monitor
registry changes and send notifications.
The state of this thread and structures used
for communicating with it are kept in the watch
variable.
The subscribe and unsubscribe functions might be
concurrently called from multiple threads and
need to communicate with the monitoring thread.
For this reason we need to synchronize the access
to the watch variable.
A new header check is added for non-standard <sys/ucred.h>. Some platforms, like Linux, might support <sys/param.h>, <sys/mount.h>, and <fstab.h> but not this. Which can cause compilation to fail for gio/gunixmounts.c
This request brings support to the latest version of QNX software. _g_get_unix_mount_points (void) for getfsent() system also works on QNX. To avoid duplicating codes, it will be reused.
Let’s not go with SHOUTY UNIX or quiet unix, let’s just call it what
Wikipedia calls it (https://en.wikipedia.org/wiki/Unix).
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
They need a `GUnixMountMonitor` to give valid timestamps, and if you
have one of those then you might as well listen to its signals anyway.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Fixes: #3569
If only someone would go ahead and invent a whole section of the list of
HTTP status codes which could be used to inform a client of where a
document has been moved to.
For the sake of argument, let’s say it could be status codes 300–399,
since they appear to be completely unused at the moment.
😩
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
The documentation for GLib and Gio contains a number of documentation
comment blocks where a parameter reference (e.g. `@err`) is also
discussed in its dereferenced pointer form, which is generally
annotated as `*@err`. This inevitably confuses the MarkDown parser,
which sees the `*` as the beginning of an italicized text span.
To avoid this, replace all `*@foo` with <code>`*foo`</code>, which
loses the `@`-sigil linking it to the `@foo` parameter, but formats
correctly in the rendered documentation. (`@foo` is automatically
formatted like <code>`foo`</code>, so the resulting appearance in
the docs is as intended.)
`@filename@` expands to the (absolute or relative) path from the
build directory to the source directory, which can be rather verbose.
In practice Meson usually (always?) generates a relative path, but
even so, the resulting installed header is not necessarily reproducible
if using different build directories outside the source directory.
We don't really need a full path here anyway: the basename is enough
of a hint to point a reader towards the file where the underlying
enum was defined.
Signed-off-by: Simon McVittie <smcv@collabora.com>
As per the previous few commits, explicitly document the established
reference counting semantics of the method call closure for
`g_dbus_connection_register_object_with_closures()`.
This isn’t ideal, but
`g_dbus_connection_register_object_with_closures()` has had these
semantics for 10 years now, and it’s a bit late to change them to
something neater.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3559
It’s not leaked, it’s transferred forwards to the eventual
`g_dbus_method_invocation_return_*()` call.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3559
This reverts commit 092fedd5f085a2f1966b5c34befe8b603c1a0f07.
This was not the right change to make, and I shouldn’t have accepted the
MR. The situation is laid out in this comment:
https://gitlab.gnome.org/GNOME/glib/-/issues/2600#note_1385050
tl;dr: The reference on the `GDBusMethodInvocation` which is transferred
in to the `GDBusInterfaceMethodCallFunc` is balanced by a reference
transferred to `g_dbus_method_invocation_return_*()`. This is how the
refcounting has always worked for these functions, and even if we’d
probably arrange things differently if the code was written now, we
can’t change those semantics without breaking API.
In particular, bindings have various bits of custom code to account for
these reference tranfers (since they can’t be represented using
gobject-introspection annotations), so changing the semantics will break
bindings.
Fixes: #3559
Parts of the `dbus-appinfo` test need support for converting an FD to a
path, and Hurd doesn’t currently allow that (see
https://gitlab.gnome.org/GNOME/glib/-/merge_requests/4396#note_2279923).
Since there’s no fix for that visible in the medium term (new kernel
APIs will need to be added), skip parts of the `dbus-appinfo` test which
require that functionality for now.
This prevents the whole test from failing, and means we can usefully get
results from the parts of it which don’t depend on converting FDs to
paths.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3538
It doesn’t list all mounts, only the ones you’d expect to see in a file
chooser sidebar.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3555
A settings schema that extends another schema should return TRUE for
all keys that are present in the extended schema. The list of keys
returned by list_keys() already includes these,
so it makes sense to include them in has_key().
Signed-off-by: Johannes Marte <johannes.marte@wolfvision.net>
Sender can be NULL if not specified by the caller, e.g. on peer-to-peer
connections.
Interface name can be NULL on method calls if it was not specified by
the sender.
Both is explicitly allowed by the DBus specification.
