Following Emmanuele's instructions for use of introspection annotations:
https://www.bassi.io/articles/2023/02/20/bindable-api-2023/
I have audited all uses of the (closure) annotation in glib and
determined that only a handful are correct. This commit changes almost
all of our use of (closure) annotations to conform to Emmanuele's rules.
We don't know how big a pthread_key_t is, so we malloc() a big enough
chunk of memory for it and store a pointer into the GPrivate struct.
It turns out, on Linux, pthread_key_t is just an int, so we could much
easier just store it directly into the struct.
https://bugzilla.gnome.org/show_bug.cgi?id=737445Fixes: #931
g_private_get_impl() was returning a pointer to the pthread_key_t, but every
function using this was immediately dereferencing it. Change it so that we
dereference the value in the helper function and return it by value.
https://bugzilla.gnome.org/show_bug.cgi?id=737445
An oversight in 86b4b045: since the comment of group N now consists of
the last null-key values of group N-1, these keys must obviously be
skipped when adding a new non-null key to group N-1.
Closes: #3047
Fixes: 86b4b0453ea3a814167d4a5f7a4031d467543716
A forgotten edge case in 86b4b045: when the last value of the last group
has been added via g_key_file_set_value() and it contains line breaks.
The best we can do in this case is probably to do nothing.
Closes: #3047
Fixes: 86b4b0453ea3a814167d4a5f7a4031d467543716
Although g_ptr_array_sort_with_data() could achieve the goal, the
wrapper functions should be expected there because that's the reason
why they are added.
To match the current widespread usage.
We can’t automatically append a colon to the group description, as that
would interact badly with translation of the string.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #3007
Just in case anyone tries to look it up using `find_program()` in a
`meson.build` in GLib (or a project pulling GLib in as a subproject) in
future.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
The code to test that `g_usleep(0)` returns immediately assumes that
`g_usleep(1)` always takes longer, but that’s not necessarily always the
case. Even if no sleeping happens, the function call for `g_usleep(0)`
could get descheduled and take longer than normal.
This results in occasional failures like this one:
```
GLib:ERROR:../glib/tests/timer.c:367:test_usleep_with_zero_wait: assertion failed (elapsed0 <= elapsed1): (0.000206 <= 0.000202)
```
(Source: https://gitlab.gnome.org/GNOME/glib/-/jobs/2898468)
I can’t think of a suitable invariant comparison which can be done with
the timers, but running the comparison 10 times and allowing it to fail
once should work. A probabilistic test of `g_usleep(0)`.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
It’s fairly consistently timing out on macOS. Looking at the verbose
test output, it’s still making progress right up until when it times out
(i.e. it hasn’t hit a `GRecMutex` bug and hasn’t deadlocked), so it
seems that the test runner is just hopelessly overloaded/underpowered
for the number of threads and iterations we’re asking it to test.
Tone those numbers down for CI test runs then.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
And dynamically allocate the arrays. This will allow the scale of the
test to be configured in the following commit, which will allow it to be
tweaked to not time out on slow CI runners.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Displaying the execution time will aid developers in understanding which
test cases are responsible for slow execution times. The test code is
already measuring the execution time for every test case, but is not
reporting that data anywhere accessible to developers running the tests.
The new code will print a TAP comment:
# slow test /the/test/path executed in NN.NN secs
for any test taking longer than 0.5 seconds to run.
Example new output format:
$ ./build/glib/tests/unix
TAP version 13
# random seed: R02S690dc3c7a04866e4890501eedc7f8eef
1..13
# Start of glib-unix tests
ok 1 /glib-unix/pipe
# /glib-unix/pipe-stdio-overwrite summary: Test that g_unix_open_pipe() will use the first available FD, even if it?s stdin/stdout/stderr
# Bug Reference: https://gitlab.gnome.org/GNOME/glib/-/issues/2795
ok 2 /glib-unix/pipe-stdio-overwrite
ok 3 /glib-unix/error
ok 4 /glib-unix/nonblocking
ok 5 /glib-unix/sighup
# slow test /glib-unix/sighup executed in 0.50 secs
ok 6 /glib-unix/sigterm
# slow test /glib-unix/sigterm executed in 0.50 secs
ok 7 /glib-unix/sighup_again
# slow test /glib-unix/sighup_again executed in 0.50 secs
ok 8 /glib-unix/sighup_add_remove
ok 9 /glib-unix/sighup_nested
ok 10 /glib-unix/callback_after_signal
# slow test /glib-unix/callback_after_signal took 2.00 secs
ok 11 /glib-unix/child-wait
# Start of get-passwd-entry tests
# /glib-unix/get-passwd-entry/root summary: Tests that g_unix_get_passwd_entry() works for a known-existing username.
ok 12 /glib-unix/get-passwd-entry/root
# /glib-unix/get-passwd-entry/nonexistent summary: Tests that g_unix_get_passwd_entry() returns an error for a nonexistent username.
ok 13 /glib-unix/get-passwd-entry/nonexistent
# End of get-passwd-entry tests
# End of glib-unix tests
As a practical usage example, the meson log can be queried to find
slow tests project-wide:
$ grep 'slow test' build/meson-logs/testlog.txt | sort -n -k 7 -r | head
# slow test /threadpool/basics executed in 36.04 secs
# slow test /gobject/refcount/properties-3 executed in 30.00 secs
# slow test /gio/io-basics executed in 12.54 secs
# slow test /timeout/rounding executed in 10.60 secs
# slow test /GObject/threaded-weak-ref executed in 10.42 secs
# slow test /thread/rerun-all executed in 9.84 secs
# slow test /gobject/refcount/object-advanced executed in 5.46 secs
# slow test /thread/static-rw-lock executed in 5.00 secs
# slow test /gobject/refcount/signals executed in 5.00 secs
# slow test /gobject/refcount/signals executed in 5.00 secs
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
This is useful when writing similarly low-level code, and was always true
as implemented here; let's document it so that other codebases can rely
on it.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Currently we require explicitly specifying the port when configuring a
proxy server, which is seriously weird. I take the fact that nobody
reported a bug until 2022 to indicate that almost nobody is using
proxies. Whatever. Let's assume that if no port is provided, the default
port for the protocol should be used instead.
For example, you can now specify in GNOME settings that your proxy server
is https://example.com and it will work. Previously, you had to write
https://example.com:443. Yuck!
This was originally reported as GProxyResolver bug, but nothing is
actually wrong there. It's actually GProxyAddressEnumerator that gets
tripped up by URLs returned by GProxyResolver without a default port.
This breaks GSocketClient.
Fixing this requires exposing GUri's _default_scheme_port() function to
GIO. I considered copy/pasting it since it's not very much code, but I
figure the private call mechanism is probably not too expensive, and I
don't like code duplication.
Fixes#2832
This is true for socks://, socks4://, socks4a://, and socks5://. I could
list them individually and risk breaking in the future if socks6:// ever
exists, or test for "socks" and risk breaking if a future URL scheme
begins with "socks" but doesn't use port 1080. I picked the latter.
This allows the `g_free()` wrapper introduced in the previous commit to
only be defined if `free_sized()` is actually available to improve
performance.
This avoids passing an allocation size to every `g_free()` call if it’s
not going to be used, saving a register store instruction each time.
Suggested by Marco Trevisan in
https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3252#note_1660032
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
When using GCC we can take the advantage of __builtin_object_size() to
know the allocated size of a memory area, this generally only works when
some optimization level enabled (-O1 seems enough here) and can provide
us with memory size information for lower-level optimizations.
Adds a helper to truncate UTF8 strings in the middle, allowing to make
them fit certain size constraints.
This function is modeled after similar functionality that has existed
since 2008 in nautilus and in eel before that.
It's redundant, which leads to impossible code like:
if (child_watch_source->using_pidfd)
{
if (child_watch_source->poll.fd >= 0)
close (child_watch_source->poll.fd);
GChildWatchSource uses waitpid(), among pidfd and GetExitCodeProcess().
It thus only works for child processes which the user must ensure to
exist and not being reaped yet. Also, the user must not kill() the PID
after the child process is reaped and must not race kill() against
waitpid(). Also, the user must not call waitpid()/kill() after the child
process is reaped.
Previously, GChildWatchSource would call waitpid() already when adding
the source (g_child_watch_source_new()) and from the worker thread
(dispatch_unix_signals_unlocked()). That is racy:
- if a child watcher is attached and did not yet fire, you cannot call
kill() on the PID without racing against the PID being reaped on the
worker thread. That would then lead to ESRCH or even worse, killing
the wrong process.
- if you g_source_destroy() the source that didn't fire yet, the user
doesn't know whether the PID was reaped in the background. Any
subsequent kill()/waitpid() may fail with ESRCH/ECHILD or even address
the wrong process.
The race is most visible on Unix without pidfd support, because then the
process gets reaped on the worker thread or during g_child_watch_source_new().
But it's also with Windows and pidfd, because we would have waited for
the process in g_child_watch_check(), where other callbacks could fire
between reaping the process status and emitting the source's callback.
Fix all that by calling waitpid() right before dispatching the callback.
