`read_netlink_messages()` is the callback attached to the netlink socket
(G_IO_IN). It calls `g_socket_receive_message()`. There is a race
condition that if the socket is closed while there is a pending call, we
will try to receive on a closed socket, which fails.
To avoid this, we switch the order of the operations around: first
destroy the source and then close the socket.
This is not a correct way to check if `g_socket_new_from_fd()` failed.
Instead just see if it returned `NULL` itself.
This was preventing the netlink monitor from being initialised.
Closes#1518
If something which looks like a closing tag is left unfinished, but
isn’t paired to an opening tag in the document, the error handling code
would do a null pointer dereference. Avoid that, at the cost of
introducing a new translatable error message.
Includes a test case, courtesy of pdknsk.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.gnome.org/GNOME/glib/issues/1461
(cherry picked from commit fccef3cc822af74699cca84cd202719ae61ca3b9)
When formatting the error messages for markup parsing errors, the parser
was unconditionally reading a UTF-8 character from the input buffer —
but the buffer might end with a partial code sequence, resulting in
reading off the end of the buffer by up to three bytes.
Fix this and add a test case, courtesy of pdknsk.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.gnome.org/GNOME/glib/issues/1462
(cherry picked from commit cec71705406f0b2790422f0c1aa0ff3b4b464b1b)
The source callback for a GCancellable should have the cancellable itself
as first argument.
This was not the case, and when this code was hit, we were instead trying
to treat the pointer as a CommunicateState reference and thus wrongly
deferencing it, causing a memory error and a crash.
7efd76dd6796f8 added these configure time tests to work around a bug
with older Android. Since the test didn't take Windows into account it
wrongfully applied the workaround on Windows too, breaking the build.
With meson this wasn't an issue since the check is skipped on Windows there
and our CI didn't catch this issue.
Change the test to run on Android only for meson and autotools.
This also makes it clear that the test+code can be dropped again if we stop
supporting older Android versions at some point.
These functions may be OK to leave the G_GNUC_MALLOC attribute on,
because the only valid pointers in the storage areas they return are,
themselves, new pointers.
However, it’s a lot easier to remove the attributes now than to try and
diagnose miscompilations in future. The performance impact of this is
likely to be unmeasurable. If there are performance problems caused by
this, then they can be profiled and fixed case-by-case in future,
bearing in mind the possibility for miscompilation if G_GNUC_MALLOC is
readded.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.gnome.org/GNOME/glib/issues/1465
These are our most critically incorrect uses of G_GNUC_MALLOC. See the
previous commit for details.
(Backport to 2.56: Drop the grcbox.h changes.)
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.gnome.org/GNOME/glib/issues/1465
Thanks to some great investigation by Benjamin Moody, it’s clear that
our documentation and usage of G_GNUC_MALLOC has fallen behind GCC’s
interpretation of the malloc attribute, meaning that recent versions of
GCC could miscompile code which uses G_GNUC_MALLOC incorrectly.
Update the documentation of G_GNUC_MALLOC to match the current GCC
documentation (for GCC 8.2). Following commits will drop our use of
G_GNUC_MALLOC from inappropriate functions.
Specifically, the change in GCC’s interpretation of the malloc attribute
which could cause miscompilation is that returned storage areas are now
assumed to not contain valid pointers — so realloc() cannot have the
malloc attribute, and neither can a function which returns a newly
allocated structure with fields initialised to other pointers.
(Backport to 2.56: Change the documentation to mention GLib 2.56.3
rather than GLib 2.58.)
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.gnome.org/GNOME/glib/issues/1465
It’s consistently timing out on the CI, which makes sense since it does
333 iterations of spawning a subprocess. Give it a bit more breathing
room.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
The network monitor portal interface is changing.
Version 2 is no longer using properties, but getters
instead (this lets the portal apply access control
and avoid sending information to non-networked
sandboxes).
To support both version 1 and 2 of the interface,
we stop using generated code and instead deal with
the api differences in our own code, which is not
too difficult.
Support version 1 as well
When using g_network_monitor_get_default() from another thread, it’s
possible for network-changed events to be processed after an instance of
GNetworkMonitor has been disposed, causing use-after-free problems.
Fix that by moving some of the initialisation into the GInitable.init()
chain, rather than in a main context idle callback.
This includes a unit test which probabilistically reproduces the bug
(but can’t do so deterministically due to it being a race condition).
Commit amended by Philip Withnall <withnall@endlessm.com> before
pushing.
https://bugzilla.gnome.org/show_bug.cgi?id=793727
While mountpoints are *not* symlinks, strictly speaking,
they works in a similar enough way, so consider them to be
symlinks for the purpose of querying local file info.
On Windows st_ctime field is the file creation time.
POSIX mandates that field to be the file state change time.
Naturally, glib code interpreted st_ctime as POSIX suggested,
and the result was bad.
Fix this by introducing special W32-only logic for setting
attributes from st_ctime field.
Fixes issue #1452.
Releasing GVolumeMonitor before g_volume_mount finish cause that
g_volume_get_mount returns NULL, because the mount is not correctly
propagated to the volume.
(Backported from commit 88b8ebb5dde0512fd1e098efe4c217111876d252 with
minor merge conflicts.)
https://gitlab.gnome.org/GNOME/glib/issues/1458
The documentation claims that g_volume_get_mount should succeed after
g_volume_mount. Let's update mounts before releasing g_volume_mount to
be sure that the mount is added to the corresponding volume. The same
is done in GVfsUDisks2VolumeMonitor.
(Backported from commit 9b6b282e0a9d3f37865aa36e21ea57bd2a326e20 with no
merge conflicts.)
https://gitlab.gnome.org/GNOME/glib/issues/1458
gunixmounts: Stop considering cifs/nfs as system file systems
See merge request GNOME/glib!125
(cherry picked from commit 51132b1d49c184f49baafa81ce7fac02b1458643)
a3a6c516 gunixmounts: Stop considering cifs/nfs as system file systems
The way things were before: a FreedesktopNotification struct is
allocated before the dbus call, and this same struct is possibly re-used
for other dbus calls. If the server becomes unavailable, the callback
will be invoked after the call times out, which leaves a long time where
other dbus calls can happen, re-using the same FreedesktopNotification
as user data. When the first call times out, the callback is invoked,
and the user data is freed. Subsequent calls that used the same user
data will time out later on, and try to free a pointer that was already
freed, hence segfaults.
This bug can be reproduced in Cinnamon 3.6.7, as mentioned in:
<https://github.com/linuxmint/Cinnamon/issues/7491>
This commit fixes that by always allocating a new
FreedesktopNotification before invoking dbus_call(), ensuring that the
callback always have a valid user data.
Signed-off-by: Arnaud Rebillout <elboulangero@gmail.com>
Don’t update to the full CI setup from master, since its success depends
on other fixes which are only present in master. However, using v1 of
the Docker image is no longer possible since it’s been removed from the
registry. Using v3 should enable CI builds for glib-2-56 to succeed.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Previously, calling:
g_dbus_is_supported_address ("some-imaginary-transport:", NULL)
correctly returned FALSE; but calling:
g_dbus_is_supported_address ("some-imaginary-transport:", &error)
crashed with:
GLib-GIO:ERROR:../gio/gdbusaddress.c:434:g_dbus_is_supported_address:
assertion failed: (ret || (!ret && (error == NULL || *error != NULL)))
This was because, if the address component did not start with a known
transport, no error was set. Fix this, reusing an error string used by
the corresponding else branch in g_dbus_address_connect(), and adjust
the test to pass both NULL and non-NULL GError **s to this function in
every test case. This case:
g_assert (!g_dbus_is_supported_address ("some-imaginary-transport:foo=bar;unix:path=/this/is/valid", NULL));
would have caught this bug with a non-NULL GError **.
Previous version of this function started with a call to g_utf8_to_utf16(),
which also served as a NULL check, since g_utf8_to_utf16() just returns NULL
on NULL strings. Current version of this function does some filename string
checks first and converts it to utf16 only after these checks are done, and
these checks do not take into account the possibility of filename being NULL.
Fix this by explicitly checking for NULL.
The existing implementation was completely incorrect (despite the fix in
commit 566e64a66) — it always compared GVariants by pointer, rather than
by value.
Reimplement it to compare them by value where possible, depending on
their type. The core of this implementation is g_variant_compare(). See
the documentation and tests for further details of the new sort order.
This adds documentation and tests.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=795735
