These are one-time allocations which are still reachable at the end of
the process. They cause warnings like this in valgrind:
```
==14408== 128 bytes in 1 blocks are definitely lost in loss record 1,287 of 1,403
==14408== at 0x4847A40: realloc (vg_replace_malloc.c:1649)
==14408== by 0x48CCD6E: g_realloc (gmem.c:201)
==14408== by 0x48F4CB1: g_string_expand (gstring.c:82)
==14408== by 0x48F4D59: g_string_sized_new (gstring.c:113)
==14408== by 0x48F4D91: g_string_new (gstring.c:134)
==14408== by 0x48A5805: g_build_path_va (gfileutils.c:1929)
==14408== by 0x48A62D1: g_build_filename_va (gfileutils.c:2222)
==14408== by 0x48A63FE: g_build_filename (gfileutils.c:2316)
==14408== by 0x491CD89: g_build_user_data_dir (gutils.c:1879)
==14408== by 0x491CDCF: g_get_user_data_dir (gutils.c:1920)
==14408== by 0x4B51E53: _g_content_type_set_mime_dirs_locked (gcontenttype.c:145)
==14408== by 0x4B51F33: g_content_type_set_mime_dirs (gcontenttype.c:194)
==14408== by 0x40C222: main (desktop-app-info.c:1880)
```
For example in https://gitlab.gnome.org/GNOME/glib/-/jobs/3278564
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
When `--attributes` is specified and doesn’t include `standard::name` in
its list, `gio` would print a critical warning from the (mandatory) call
to `g_file_info_get_name()`.
Fix that by making the call to `g_file_info_get_name()` optional.
Add a unit test too.
Signed-off-by: Philip Withnall <philip@tecnocode.co.uk>
Fixes: #3158
It gives nowhere near full coverage, but it’s something we can build on
in future.
Signed-off-by: Philip Withnall <philip@tecnocode.co.uk>
Helps: #3158
Helps: #2950
Modify all the similar Python test wrappers to set
`G_DEBUG=fatal-warnings` in the environment of the program being tested,
so we can catch unexpected warnings/criticals.
Adding this because I noticed it was missing, not because I noticed a
warning/critical was being ignored.
Signed-off-by: Philip Withnall <philip@tecnocode.co.uk>
If the help output is explicitly requested by the user, it’s
conventional for it to be printed to stdout rather than stderr.
Signed-off-by: Philip Withnall <philip@tecnocode.co.uk>
Store their details in an array which can be iterated over instead.
This introduces no functional changes, just a cleanup which will allow
following commits to be neater.
Signed-off-by: Philip Withnall <philip@tecnocode.co.uk>
Mention that ready time being equal to the current time means the source
will fire immediately.
Related to https://gitlab.gnome.org/GNOME/glib/-/issues/3148
Signed-off-by: Sergey Bugaev <bugaevc@gmail.com>
If she socket is dispatched at exactly the previously set ready time,
it should already be considered to have timed out. This can easily
happen in practice when using a low resolution timer.
This fixes a test failure on GNU/Hurd, see
https://gitlab.gnome.org/GNOME/glib/-/issues/3148
Signed-off-by: Sergey Bugaev <bugaevc@gmail.com>
Instead of tracking a "(guint,GSource*)" tuple in the "context->sources"
dictionary, only track pointers to the "source_id".
With this we use the GHashTable as Set (g_hash_table_add()), which is
optimized and avoids storing a separate value array.
It's simple enough to do, because there are literally 5 references to
"context->sources". It's easy to review those usages and reason that the
handling is correct.
While at it, in g_main_context_find_source_by_id() move the check for
SOURCE_DESTROYED() inside the lock. It's not obvious that doing this
without a lock was correct in every case. But doing the check with
a lock should be fast enough to not worry about whether it's absolutely
necessary.
We have g_int_hash()/g_int_equal(), which in practice might also work
with with pointers to unsigned integers. However, according to strict
interpretation of C, I think it is not valid to conflate the two.
Even if it were valid in all cases that we want to support, we should
still have separate g_uint_{hash,equal} functions (e.g. by just #define
them to their underlying g_int_{hash,equal} implementations).
Add instead internal hash/equal functions for guint.
Previously thread-pool-slow ran a single test which encoded a state
machine and polling timer to run 8 different sub-tests and check for
their exit conditions.
This was a bit ugly, and since the timer ran at 1s granularity, several
of the tests completed quite fast and then hang around for most of 1s
before finishing and moving to the next test.
Split the test functions up into separate GTest tests, and split the
state machine up between the test functions. All of the `GMainLoop`
handling is actually only needed for the `test_threadpool_idle_time()`
test.
This reduces the overall test runtime from 36s to 19s on my machine,
with 17s of that being spent in `test_threadpool_idle_time()`.
Signed-off-by: Philip Withnall <philip@tecnocode.co.uk>
Helps: #2810
This makes things a bit more maintainable, as there’s less global state
to worry about.
It introduces no functional changes.
Signed-off-by: Philip Withnall <philip@tecnocode.co.uk>
The race was already acknowledged in the code (via `last_failed`): the
thread pool starts dequeuing jobs as soon as it’s created, so it’s
dequeuing the sorted thread IDs while they’re still being enqueued and
sorted. This can lead to them being dequeued out of the expected order
if new thread IDs are enqueued out of order, which is possible because
they’re randomly generated.
The test tried to handle this by allowing one out-of-order dequeue, but
it looks like the race can race hard enough that multiple out-of-order
dequeues are possible.
Fix that by only starting to dequeue the jobs from the thread pool once
they’ve all been enqueued and put in a total order.
Signed-off-by: Philip Withnall <philip@tecnocode.co.uk>
Fixes: #2810
The test only needs a unidirectional channel, and a pipe is sufficient
for that.
This may simplify things when running the test on Hurd; see
https://gitlab.gnome.org/GNOME/glib/-/issues/3148#note_1874198.
Additionally, set `O_NONBLOCK` on the pipe since the test seems to
expect that partial writes will succeed and that writes to a full buffer
will fail rather than block.
Signed-off-by: Philip Withnall <philip@tecnocode.co.uk>
Helps: #3148
