This code was a persistent source of `-fsanitize=thread` errors
when I was trying to use it on OSTree.
The problem is that while I think this code is functionally correct,
we hold a mutex during the writes, but not the reads, and TSAN (IMO
correctly) flags that.
Reading this, I don't see a reason we need a mutex at all. At the
cost of some small code duplication between posix/win32, we can just
pass the data we need down into each implementation. This ends up
being notably cleaner I think than the awkward "lock/unlock to
serialize" dance.
(Minor review changes made by Philip Withnall <withnall@endlessm.com>.)
https://gitlab.gnome.org/GNOME/glib/issues/1224
I'm trying to use `-fsanitize=thread` for OSTree, and some of
these issues seem to go into GLib. Also, the sanitizers work better if
the userspace libraries are built with them too.
This fix is similar to
b6814bb37c
Mixing atomic and non-atomic reads trips TSAN, so let's change the
assertions to operate on the local values returned from atomic
read/writes.
Without this change I couldn't even *build* GLib with TSAN, since we
use gresources during compilation, which uses GSubprocess, which hits
this code.
(Minor review fixes made by Philip Withnall <withnall@endlessm.com>.)
https://gitlab.gnome.org/GNOME/glib/issues/1224
A lot of code cast function pointer to incorrect types. There is no
other way but silencing the warning. Follows an example of such cast:
glib/glist.c: In function ‘g_list_free_full’:
glib/glist.c:223:25: error: cast between incompatible function types from ‘GDestroyNotify’ {aka ‘void (*)(void *)’} to ‘void (*)(void *, void *)’ [-Werror=cast-function-type]
g_list_foreach (list, (GFunc) free_func, NULL);
^
glib/deprecated/gthread-deprecated.c: In function ‘g_static_rec_mutex_init’:
glib/deprecated/gthread-deprecated.c:657:3: error: missing initializer for field ‘depth’ of ‘GStaticRecMutex’ {aka ‘const struct _GStaticRecMutex’} [-Werror=missing-field-initializers]
static const GStaticRecMutex init_mutex = G_STATIC_REC_MUTEX_INIT;
^~~~~~
In file included from glib/deprecated/gthread-deprecated.c:30:
glib/deprecated/gthread.h:161:9: note: ‘depth’ declared here
guint depth;
^~~~~
This never caused any problems because the default GSettingsBackend is
cached forever by GIOModule anyway.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
I was trying to debug some memory leaks in the gsettings test.
Eventually, it seems that actually they’re caused by the
GMemorySettingsBackend being cached by GIOModule — so this commit makes
no functional changes. It should make the code and documentation a bit
clearer though.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
This mostly affects the 2.56 branch, but, given that GCC 9 is being
stricter about passing null string pointers to printf-like functions, it
might make sense to proactively fix such calls.
gdbusauth.c: In function '_g_dbus_auth_run_server':
gdbusauth.c:1302:11: error: '%s' directive argument is null
[-Werror=format-overflow=]
1302 | debug_print ("SERVER: WaitingForBegin, read '%s'",
line);
|
gdbusmessage.c: In function ‘g_dbus_message_to_blob’:
gdbusmessage.c:2730:30: error: ‘%s’ directive argument is null [-Werror=format-overflow=]
2730 | tupled_signature_str = g_strdup_printf ("(%s)", signature_str);
|
The recent changes of the g_app_info_launch_default_for_uri_async()
function ensures that the callback is not called before DBus-activated
applications start. Let's use g_app_info_launch_default_for_uri_async()
and remove the workarounds for DBus-activated applications.
Closes: https://gitlab.gnome.org/GNOME/glib/issues/1249
The g_app_info_launch_uris_async() and g_app_info_launch_uris_finish()
functions are crucial to fix g_app_info_launch_default_for_uri_async()
to be really asynchronous.
This patch also adds GDesktopAppInfo implementation of that vfuncs.
The implementation may still use some synchronous calls to local MIME DB.
https://gitlab.gnome.org/GNOME/glib/issues/1347https://gitlab.gnome.org/GNOME/glib/issues/1249
glib/garray.c: In function ‘g_ptr_array_insert’:
glib/garray.c:1522:14: error: comparison of integer expressions of different signedness: ‘gint’ {aka ‘int’} and ‘guint’ {aka ‘unsigned int’} [-Werror=sign-compare]
if (index_ < rarray->len)
^
glib/gdatetime.c: In function ‘get_iso8601_int’:
glib/gdatetime.c:1142:17: error: comparison of integer expressions of different signedness: ‘gint’ {aka ‘int’} and ‘gsize’ {aka ‘long unsigned int’} [-Werror=sign-compare]
for (i = 0; i < length; i++)
^
glib/gdatetime.c: In function ‘get_iso8601_seconds’:
glib/gdatetime.c:1175:9: error: comparison of integer expressions of different signedness: ‘gint’ {aka ‘int’} and ‘gsize’ {aka ‘long unsigned int’} [-Werror=sign-compare]
if (i == length)
^~
glib/gdatetime.c:1178:12: error: comparison of integer expressions of different signedness: ‘gint’ {aka ‘int’} and ‘gsize’ {aka ‘long unsigned int’} [-Werror=sign-compare]
for (; i < length; i++)
^
In file included from glib/glibconfig.h:9,
from glib/gtypes.h:32,
from glib/gtimezone.h:27,
from glib/gdatetime.h:31,
from glib/gdatetime.c:62:
glib/gdatetime.c: In function ‘initialize_alt_digits’:
glib/gdatetime.c:2806:27: error: comparison of integer expressions of different signedness: ‘gsize’ {aka ‘long unsigned int’} and ‘long int’ [-Werror=sign-compare]
g_assert (digit_len < buffer + sizeof (buffer) - buffer_end);
^
glib/gmacros.h:455:25: note: in definition of macro ‘G_LIKELY’
#define G_LIKELY(expr) (expr)
^~~~
glib/gdatetime.c:2806:7: note: in expansion of macro ‘g_assert’
g_assert (digit_len < buffer + sizeof (buffer) - buffer_end);
^~~~~~~~
glib/gchecksum.c: In function ‘digest_to_string’:
glib/gchecksum.c:186:17: error: comparison of integer expressions of different signedness: ‘gint’ {aka ‘int’} and ‘gsize’ {aka ‘long unsigned int’} [-Werror=sign-compare]
for (i = 0; i < digest_len; i++)
^
glib/gdataset.c: In function ‘g_datalist_clear_i’:
glib/gdataset.c:233:21: error: comparison of integer expressions of different signedness: ‘gint’ {aka ‘int’} and ‘guint32’ {aka ‘unsigned int’} [-Werror=sign-compare]
for (i = 0; i < data->len; i++)
^
glib/gdataset.c: In function ‘g_datalist_clear’:
glib/gdataset.c:270:21: error: comparison of integer expressions of different signedness: ‘gint’ {aka ‘int’} and ‘guint32’ {aka ‘unsigned int’} [-Werror=sign-compare]
for (i = 0; i < data->len; i++)
^
glib/gdataset.c: In function ‘g_datalist_foreach’:
glib/gdataset.c:1147:21: error: comparison of integer expressions of different signedness: ‘int’ and ‘guint32’ {aka ‘unsigned int’} [-Werror=sign-compare]
for (j = 0; j < d->len; j++)
^
../glib.git/glib/garray.c: In function ‘g_ptr_array_maybe_expand’:
../glib.git/glib/garray.c:1172:43: error: comparison of integer expressions of different signedness: ‘unsigned int’ and ‘gint’ {aka ‘int’} [-Werror=sign-compare]
if G_UNLIKELY ((G_MAXUINT - array->len) < len)
../glib.git/glib/gtester.c: In function ‘sindent’:
../glib.git/glib/gmacros.h:351:26: error: comparison of integer expressions of different signedness: ‘guint’ {aka ‘unsigned int’} and ‘int’ [-Werror=sign-compare]
#define MIN(a, b) (((a) < (b)) ? (a) : (b))
^
../glib.git/glib/gtester.c:73:7: note: in expansion of macro ‘MIN’
n = MIN (n, l);
^~~
../glib.git/glib/gmacros.h:351:41: error: operand of ?: changes signedness from ‘int’ to ‘guint’ {aka ‘unsigned int’} due to unsignedness of other operand [-Werror=sign-compare]
#define MIN(a, b) (((a) < (b)) ? (a) : (b))
^~~
../glib.git/glib/gtester.c:73:7: note: in expansion of macro ‘MIN’
n = MIN (n, l);
^~~
In the writev() tests, the handling of cancellation is tested. However,
the GCancellable was cancelled after the writev_async() call was
started. Depending on the implementation of the writev() vfunc, the
operation could be done in a thread or in callbacks on the current
thread’s main loop. If done in a separate thread, there’s a chance that
enough of the write could happen before cancellation reaches that thread
that the overall operation returns success with a short write.
That would cause the test to fail, sometimes.
Avoid that by cancelling the GCancellable before starting the writev()
operation.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Reviewed-by: nobody
