It might be possible for the `low-memory-warning` signal to be emitted
(by the GLib worker thread) before the test has connected to it, which
could cause the tests to loop forever.
Potentially fixes
https://gitlab.gnome.org/pwithnall/glib/-/jobs/5322491, though I have
not been able to reproduce the race locally.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
If the first `goto out` is taken, `file` has not yet been initialised,
but `g_clear_object (&file)` is called on it, and things get unhappy.
Fix that by following standard convention and initialising
‘autoptr’-like variables at declaration time.
Spotted by scan-build in
https://gitlab.gnome.org/GNOME/glib/-/jobs/5321883.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
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
