When checking whether a serialised GVariant tuple is in normal form,
it’s possible for `offset_ptr -= offset_size` to underflow and wrap
around, resulting in gvs_read_unaligned_le() reading memory outside the
serialised GVariant bounds.
See §(Tuples) in gvariant-serialiser.c for the documentation on how
tuples are serialised. Briefly, all variable-length elements in the
tuple have an offset to their end stored in an array of offsets at the
end of the tuple. The width of each offset is in offset_size. offset_ptr
is added to the start of the serialised tuple to get the offset which is
currently being examined. The offset array is in reverse order compared
to the tuple elements, hence the subtraction.
The bug can be triggered if a tuple contains a load of variable-length
elements, each of whose length is actually zero (i.e. empty arrays).
Includes a unit test.
oss-fuzz#9801
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Emulated futexes are slower than real ones; if they were not, there
would be no point in using the real futexes. On some machines they
are sufficiently slow to cause test timeouts.
Signed-off-by: Simon McVittie <smcv@collabora.com>
G_FILE_ATTRIBUTE_ACCESS_CAN_TRASH can be set to a wrong value if
its parent dir is a symlink. This is because the find_mountpoint_for()
function tries to find mountpoint for a filepath and expands symlinks
only in parent dirs. But in this case the path is already parent dir
and needs to be expanded first...
Closes: https://gitlab.gnome.org/GNOME/glib/issues/1522
Fedora is using https://fedoraproject.org/wiki/Changes/Annobin
to try to ensure that all objects are built with hardening flags.
Pass down `CFLAGS` to ensure the SystemTap objects use them.
Without gatomic.h, build fails on:
In file included from garcbox.c:24:0:
garcbox.c: In function ‘g_atomic_rc_box_acquire’:
grefcount.h:101:13: error: implicit declaration of function ‘g_atomic_int_get’; did you mean ‘__atomic_store’? [-Werror=implicit-function-declaration]
(void) (g_atomic_int_get (rc) == G_MAXINT ? 0 : g_atomic_int_inc ((rc))); \
^
garcbox.c:292:3: note: in expansion of macro ‘g_atomic_ref_count_inc’
g_atomic_ref_count_inc (&real_box->ref_count);
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
We unconditionally appended ">= $min_glib_version" to the modules to
look for, even though we had already included
"glib-2.0 >= $min_glib_version" in our list. When requesting additional
modules, this was fine, for example
AM_PATH_GLIB_2_0([2.58], [:], [:], [gobject gio])
ended up asking pkg-config for
glib-2.0 >= 2.58 gobject-2.0 gio-2.0 >= 2.58
which is redundant (since they all share a version number) but
otherwise OK.
However,
AM_PATH_GLIB_2_0([2.58], [:], [:], [])
ended up asking pkg-config for
glib-2.0 >= 2.58 >= 2.58
which is not OK; the second ">=" was parsed as a bizarrely-named package
to check for, and obviously few people have ">=.pc" installed.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Fixes: 4bb16f48 "m4macros: Allow information from pkg-config to be overridden"
An assertion is harder to skip over, and using a g_critical() can give
us a more informative error message.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.gnome.org/GNOME/glib/issues/179
All pool threads are named "pool" and this a bit annoying when looking
at system-wide traces or statistics for a system where several
applications use thread pools. Include the prgname in the thread names
to get a better default name. The total length including the "pool-"
prefix is limited to 16 bytes in order for it to work on all systems.
Change-Id: I473a9f534c4630f3e81da72ff96d8f593c60efac
Since we are unable to promote our FreeBSD runner to a shared runner,
we can only enable it in GNOME group. This should avoid problems when
submitting merge requests from forks.
A double paren forces the compiler to assume that the
statement is right. That may not be the case.
This is essentially reverting b44fba25fb.
See https://bugzilla.gnome.org/show_bug.cgi?id=760215.
It's more morth to allow find common mistakes (= instead of ==
in conditionals) than masking them to make some rarely used
code work.
While we can’t add markers to the macro implementations to cause lcov to
ignore them automatically, we can change our lcov configuration to
ignore all calls to them.
See https://github.com/linux-test-project/lcov/issues/44.
This causes all the un-takeable branches and un-reachable assertions to
be ignored by our code coverage, which bumps our statistics:
• Lines: 74.9% → 74.8%
• Functions: 82.3% → 82.3%
• Branches: 53.3% → 64.2%
The rationale is that nobody should be testing programmer error
handling, as g_return_*if_fail() are used to guard against — so it’s not
reasonable to count missed branches like that in code coverage
statistics.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
By using PKG_CHECK_VAR, we declare $GLIB_COMPILE_SCHEMAS,
$GLIB_GENMARSHAL, $GOBJECT_QUERY, $GLIB_MKENUMS and
$GLIB_COMPILE_RESOURCES as Autoconf "precious variables" with AC_ARG_VAR,
similar to $PKG_CONFIG and $CC, so that they can be put on a configure
command line:
./configure GLIB_COMPILE_RESOURCES=my-glib-compile-resources
If they are set to a non-empty value, PKG_CHECK_VAR will use that
instead of auto-detecting from pkg-config, so that builders can
override them, for example when cross-compiling.
Similarly, use the standard PKG_CHECK_MODULES macro to get GLib's CFLAGS
and LIBS.
It's possible that most of the rest of each macro can also disappear,
but for the moment I've given them the benefit of the doubt.
This does result in printing "checking for GLIB" twice (once for
PKG_CHECK_MODULES and once for GLib's custom checks), but if you're
using Autotools, you probably don't have a strong objection to overly
verbose output.
Signed-off-by: Simon McVittie <smcv@collabora.com>
When using glib as a meson subproject on Windows the build currently fails
due to too long paths during the build process. See
https://github.com/mesonbuild/meson/issues/4226 for the upstream bug.
To work around the issue shorten the filenames of the generated gdbus files.
The tests were making assumptions about the order of the returned D-Bus
introspection nodes. However, these are semantically unordered and
changes to e.g. GHashTable would break the tests.
Fix this by applying a sort prior to validation.
We still clear the key/value on removal, but since we're growing the
arrays with realloc() now, we can't guarantee that incoming memory is
cleared. There's no reason it should be either, since we check the
hashes array (which is always in a defined state) before accessing the
other arrays.
When g_hash_table_resize() gets called, we clear out tombstones and grow
the table at the same time if needed. However, the threshold was set too
low, so we'd grow if the load was greater than .5 after subtracting
tombstones. Increase this threshold to ~.75.
When resizing, we were keeping both the old and new hash, key and value
arrays around while we reinserted entries, resulting in a peak memory
overhead of 50%. Using a temporary bookkeeping array with one bit per
entry we can now grow and shrink the main arrays using realloc() and an
eviction scheme, reducing the overhead to .625% (assuming 64-bit keys and
values). Tests show the CPU overhead is negligible.
If int is smaller than void * on our arch, we start out with
int-sized keys and values and resize to pointer-sized entries as
needed. This saves a good amount of memory when the HT is being
used with e.g. GUINT_TO_POINTER().
I’m fed up of trying to read these and having my head done in by mixed
tabs and spaces.
This introduces no functional changes.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
This partially reverts commit bfc362cb68.
The FreeBSD CI runner still seems to be a bit flakey, and appears to be
offline entirely at the moment.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Reviewed-by: nobody
