As with the previous commit, but for `g_socket_connect()`, which is the
other cancellable use of `g_socket_condition_wait()` in the file.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Currently, if `g_socket_accept()` is called with a cancelled cancellable
and the socket is in non-blocking mode, `G_IO_ERROR_CANCELLED` is not
returned, because the cancellable is only checked in the call to
`g_socket_condition_wait()`, which only happens in blocking mode.
Fix that and add a unit test.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3739
`GMemoryMonitor` is a singleton, which means we can’t use the usual
approach of emitting signals in the thread-default main context from the
time of construction of the object.
The next best thing is to emit them in the global default main context.
For many applications, this will be exactly what they are expecting. For
multi-threaded applications, they will need to implement their own
thread safety in the signal handler, but they would have to do that
anyway.
Currently, the signals are emitted in the GLib worker thread (for the
PSI and poll implementations of `GMemoryMonitor`) — this is the worst
option, because it means that third party signal handlers could block
the worker thread (which is precisely what the worker thread is meant to
avoid).
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
The memory free ratio test can be skipped when we run the test. If
proc_override is TRUE and proc path is overridden, the memory free
ratio test can be skipped.
The value overriding has to be set before testing the value and returning
the callback. Otherwise, the callback can't emit a signal to the test
program.
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.
