Commits on Source (13)
-
Philip Withnall authored
This allows compilers to check the format placeholders properly. It fixes compilation on clang, which gives a warning about untrusted strings being passed on to subsequent functions which require format placeholders. Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
848a5343 -
Emmanuele Bassi authored
Backport !1718 “gtrace: Add G_GNUC_PRINTF annotation” to glib-2-66 See merge request GNOME/glib!1720
cea485ac -
If there is a file descriptor source that has a lower priority than the one for sources that are going to be dispatched, all subsequent file descriptor sources (internally sorted by file descriptor identifier) do not get an update in their GPollRec and later on wrong sources can be dispatched. Fix this by first finding the first GPollRec that matches the current GPollFD, instead of relying on it to be the current one. At the same time, document the assumptions about the ordering of the file descriptor records and array and make explicit in the documentation that the array needs to be passed to g_main_context_check() as it was received from g_main_context_query(). Added a new test that reproduces the bug by creating two file descriptor sources and an idle one. Since the first file descriptor created has a lower identifier and a low priority, the second one is not dispatched even when it has the same, higher, priority as the idle source. After fixing this bug, both higher priority sources are dispatched as expected. While this patch was written independently, a similar fix for this bug was first submitted by Eugene M in GNOME/glib!562. Having a second fix that basically does the same is a reassurance that we are in the right here. Fixes #1592
fa45688f -
Philip Withnall authored
Backport !1713 “gmain: g_main_context_check() can skip updating polled FD sources” to glib-2-66 See merge request GNOME/glib!1721
614d4094 -
This test ensures that g_socket_client_connect_to_host_async() fails if it is cancelled, but it's not cancelled until after 1 millisecond. Our CI testers are hitting that race window, and Milan is able to reproduce the crash locally as well. Switching it from 1ms to 0ms is enough for Milan to avoid the crash, but not enough for our CI, so let's move the cancellation to a GSocketClientEvent callback where the timing is completely deterministic. Hopefully fixes #2221
832d09ad -
Emmanuele Bassi authored
Backport !1711 “Fix race in socketclient-slow test” to glib-2-66 See merge request GNOME/glib!1723
cfbab734 -
Suppose we are sending a 5K message with fds (so data->blob points to 5K of data, data->blob_size is 5K, and fd_list is non-null), but the kernel is only accepting up to 4K with each sendmsg(). The first time we get into write_message_continue_writing(), data->total_written will be 0. We will try to write the entire message, plus the attached file descriptors; or if the stream doesn't support fd-passing (not a socket), we need to fail with "Tried sending a file descriptor on unsupported stream". Because the kernel didn't accept the entire message, we come back in. This time, we won't enter the Unix-specific block that involves sending fds, because now data->total_written is 4K, and it would be wrong to try to attach the same fds again. However, we also need to avoid failing with "Tried sending a file descriptor on unsupported stream" in this case. We just want to write out the data of the rest of the message, starting from (blob + total_written) (in this exaple, the last 1K). Resolves: https://gitlab.gnome.org/GNOME/glib/-/issues/2074 Signed-off-by: Simon McVittie <smcv@collabora.com>
40cd84d9 -
This incidentally also exercises the intended pattern for sending fds in a D-Bus message: the fd list is meant to contain exactly those fds that are referenced by a handle (type 'h') in the body of the message, with numeric handle value n corresponding to g_unix_fd_list_peek_fds(...)[n]. Being able to send and receive file descriptors that are not referenced by a handle (as in OpenFile here) is a quirk of the GDBus API, and while it's entirely possible in the wire protocol, other D-Bus implementations like libdbus and sd-bus typically don't provide APIs that make this possible. Reproduces: https://gitlab.gnome.org/GNOME/glib/-/issues/2074 Signed-off-by: Simon McVittie <smcv@collabora.com>
60c3c948 -
Simon McVittie authored
Backport !1725 “gdbus: Cope with sending fds in a message that takes multiple writes” to glib-2-66 See merge request GNOME/glib!1727
4daaf303 -
As hidden file caches currently work, every look up on a directory caches its .hidden file contents, and sets a 5s timeout to prune the directory from the cache. This creates a problem for usecases like Tracker Miners, which is in the business of inspecting as many files as possible from as many directories as possible in the shortest time possible. One timeout is created for each directory, which possibly means gobbling thousands of entries in the hidden file cache. This adds as many GSources to the glib worker thread, with the involved CPU overhead in iterating those in its main context. To fix this, use a unique timeout that will keep running until the cache is empty. This will keep the overhead constant with many files/folders being queried.
92c19ebd -
Emmanuele Bassi authored
Backport !1734 “glocalfileinfo: Use a single timeout source at a time for hidden file cache” to glib-2-66 See merge request GNOME/glib!1736
e18a6a85 -
Philip Withnall authored
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
30c06eb5 -
Simon McVittie authored32c9765e