The length of the stolen data from a memory output stream is given by
get_data_size() — get_size() can be larger, and hence cause unnecessary
overallocation.
Closures use a 16-bit atomic reference count, which is really slow
on certain ARM64 CPUs such as the Cortex-A57 (glib#1316). This is
non-trivial to solve, since the public struct field cannot be enlarged
to 32-bit while preserving ABI, and 16-bit atomic operations would be new
(and rather niche) API.
Until this can be solved properly (hopefully in GLib 2.59.x), cut down
the number of signal emission cycles and bump up the timeout in the
Meson build system, so that builds won't time out. We can't just take
another zero off the number of signal emission cycles, as was done in the
original version of this patch in Debian, because if we do that it can
result in test failures when the main thread starves the other threads.
ARM64 CPUs are backwards-compatible with 32-bit ARM, and the same
slowdown can be seen when building and testing 32-bit code on these
CPUs, so check for both 32- and 64-bit ARM.
Bug-Debian: https://bugs.debian.org/880883
Co-authored-by: Iain Lane <laney@debian.org>
Signed-off-by: Simon McVittie <smcv@debian.org>
Rather than duplicating the alignment checks when constructing a new
GVariant, re-use the alignment checks from GVariantSerialised. This
ensures that the same checks are done everywhere in the GVariant code.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.gnome.org/GNOME/glib/issues/1342
Otherwise the GVariant would later fail internal alignment checks,
aborting the program.
If unaligned data is provided to (for example)
g_variant_new_from_data(), it will copy the data into a new aligned
allocation. This is slow, but better than crashing. If callers want
better performance, they should provide aligned data in their call, and
it will not be copied or reallocated.
Includes a unit test.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.gnome.org/GNOME/glib/issues/1342
This was causing a crash, because we were first removing an item, freeing
both the instance itself and the key, and then trying to reuse those.
So, in this case, instead of reassigning an item, we can just return TRUE
as we have already the item at the right place, while it's not needed to
update the modified timestamp, since no modification happened in reality.
Fixes#1588
Synchronize access to random number generator `test_run_rand` with
a lock to ensure that `g_test_rand_*` family of functions is
thread-safe.
The reseeding taking place between test case runs is intentionally left
unsynchronized. It is an error to continue using random number generator
after test case has already finished running. Lack of synchronization
here will make such erroneous use readily apparent with thread
sanitizer.
This test isn't inherently slow, but it produces so much output that
it can take a minute or more on hardware with weak I/O performance.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This is enough for most Debian buildds, including embedded devices
like mips and powerpcspe. It is not enough for hppa (PA-RISC), but that
architecture is so uniquely slow that it might make more sense to
special-case it downstream.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This reverts commits:
• 9ddcc79502
• ae02adc3c3
g_date_time_format() supports a few non-standard format placeholders:
• %:z
• %::z
• %:::z
These are all gnulib strtime() extensions, and hence are not recognised
by the compiler when the function is annotated with G_GNUC_STRFTIME.
However, this wasn’t noticed when we originally merged this change
because the errors were disabled in the tests which covered those
placeholders.
This does not work, since g_date_time_format() supports
non-standard extensions such as %:::z, and this has
broken several consumers which use format errors, such
as ostree.
This is desirable both to get more detailed failure messages; and
because g_assert() is compiled out when compiling with G_DISABLE_ASSERT,
which renders the tests useless.
Signed-off-by: Christophe Fergeau <cfergeau@redhat.com>
gint is not the best type when looping from 0 to N > 0, which usually is
the case in loops. There are a few cases in this patch where guint is
used rather than gsize, this is when the index is used in a printf-like
function as this makes the format string easier to read
Signed-off-by: Christophe Fergeau <cfergeau@redhat.com>
