The `mainloop` test suite takes about 775s on my machine under valgrind
with this test enabled, vs 50s without this test enabled.
This causes CI failures like
https://gitlab.gnome.org/GNOME/glib/-/jobs/5321882.
I’m not sure that valgrind will actually successfully reproduce the race
condition because it runs too slowly (but I haven’t verified that by
reverting the fix for the race).
In any case, you can still choose to run the test under valgrind with
`-m thorough`.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
This backend periodically watch the memory free ratio through sysinfo().
It signals the applications when the memory free ratio drops to 40%, 30%,
and 20% for LOW, MEDIUM, CRITICAL status, respectively.
The PSI backend is based on Kernel PSI [1]. It monitors the memory
allocation time with in a given time window. If the allocation time
is more than the given threshold, Kernel signal the application to
deliver the memory pressure events.
The current thresholds are:
LOW: 70ms out of 2 seconds for partial stall
MEDIUM: 100ms out of 2 seconds for partial stall
CRITICAL: 100ms out of 2 seconds for full stall
[1] https://docs.kernel.org/accounting/psi.html
This class provides the shared functions, such as sending a signal and
string and value conversion. The backend classes should inherit this
class to get the shared functions.
It adds a configure time check for `sysinfo()`, as some systems don’t
have it.
This will catch regressions like
fc030b2b64 if they happen again in future,
by testing that fallback argument parsing code path in
`g_application_run()`.
Heavily based on the PyGObject `test_local_and_remote_command_line` unit
test at
578a55982a/tests/test_gio.py (L289).
Thanks to Arjan Molenaar for investigating the failure and writing it
up in !4703.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Do an extra check if the options argument is NULL,
This will avoid unnessecary (critical warning).
`g_application_run` calls the code with options == NULL.
The array buffer is of size BUFSIZE. The if-check correctly avoids
writing characters into the buffer, but the ending newline may still
overflow buffer. Keep space for the EOL character.
If an array with more than INT_MAX elements is passed to functions
internally calling g_build_path_va or g_build_pathname_va, then a
signed integer overflow and eventual out of boundary read access can
occur.
Use size_t instead of gint for lengths and array sizes.
The g_array_copy function uses elt_capacity as length argument for
g_array_sized_new. With a zero terminated array, this effectively
means that the next allocation is doubled in size.
Avoid this by doing the same as g_ptr_array_copy, i.e. use the length.
This makes sure that elt_capacity is roughly the same (only differs
if the copied array has unallocated data in it).
If supplied data argument is not NULL, then add the actually existing
null/zero terminated element to alloc/elt_capacity. Otherwise the
termination element is not taken into account, because the length only
counts the non-termination elements.
Purely defensive measurement. I don't think that this triggered any
bug (only one needless realloc call if set_size functions are called
with the current length).
The functions g_array_new and g_array_sized_new already protect
themselves against a zero element size.
Do the same in g_array_new_take and g_array_new_take_zero_terminated
to avoid a NULL pointer dereference and an endless loop.
Apply GArray's g_array_maybe_expand overflow checking logic to
GPtrArray's g_ptr_array_maybe_expand function:
Let g_ptr_array_maybe_expand handle the null_terminated flag internally
to check if an overflow occurs instead of letting callers do these
check on their own.
The g_ptr_array_copy function lacked this check.
Having a centralized position for this check simplifies the code and
further code auditings.
The functions g_array_new_take_zero_terminated and
g_ptr_array_new_take_null_terminated must take into account that the
last element will be the terminating element (zero filled or NULL).
Iterating through all elements must not reach G_MAXUINT, because in
that case no space is left for the terminating element.
Call these vfuncs also for cases where the launching instance
is the primary one. This is what the docs suggest, and it makes
before/after_emit much more useful.
Fixes: #3726
Existing uses of before_emit in GTK will break if an app overrides
before/after_emit without chaining up. Clarify in the documentation
that these vfuncs need to chain up.
The dbus-appinfo test was asserting that before_emit only happens
when we haven't seen a startup ID yet. But the docs imply that it
gets emitted for every activate/open/commandline, which may well
happen repeatedly. So drop this assertion.
The g_array_new_take_zero_terminated function could lead to NULL
data pointer if it is called with (NULL, FALSE, x), i.e. with a NULL
pointer and no clear request.
This in turn means that g_array_steal could behave like
g_ptr_array_steal, i.e. it would return NULL instead of a zero
terminated array, which does not match its description.
Also, g_array_remove_range and g_array_set_size could lead to NULL
pointer dereferences with such arrays.
Support all these cases and adjust the API description to reflect
current behavior. It brings GArray and GPtrArray functionality closer
to each other without breaking existing API/ABI for programs.
The g_string_append_vprintf function could overflow with strings
which are INT_MAX bytes long. The eventual memcpy call copies INT_MAX
plus additional nul byte into newly allocated memory. This means
that due to signed integer overflow more bytes are copied than
could ever fit.
The multiplication of two guint values could overflow with large
arrays. Use g_array_elt_len and g_array_elt_pos to avoid explicit
elt_size multiplications.
