These tests are expected to cause a thread to deadlock. That seems to be
fine with glibc on Linux, but the glibc version on FreeBSD can detect
the deadlock, and aborts the whole test process with:
```
GLib (gthread-posix.c): Unexpected error from C library during 'pthread_mutex_lock': Resource deadlock avoided. Aborting.
```
This is fair enough.
To avoid this causing the test suite to fail, run those two tests in
subprocesses. This also means we’re not carrying a deadlocked thread
around for the rest of the test suite.
Improves on commit 62192925b6.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
And size it to `sysconf (_SC_MINSIGSTKSZ)`, if defined.
This might fix the sigaltstack test on muslc, as suggested by Markus
Wichmann (https://www.openwall.com/lists/musl/2024/05/30/2) and Rich Felker
(https://www.openwall.com/lists/musl/2024/05/29/7) on the musl mailing
list.
The thinking is that the CI machine might have a huge register file
(AVX512 or some other large extension) which doesn’t fit in `MINSIGSTKSZ`.
By sizing the alternate stack to `sysconf (_SC_MINSIGSTKSZ)` we should
be able to avoid that.
Moving it onto the heap should avoid any potential complications or bugs
from having one stack embedded within another.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Fixes: #3315
Provide examples of what they all represent, and expand on the
descriptions of them in a few places.
Move references to their equivalents from `GnomeVFS` to lower down in
the documentation, since `GnomeVFS` has been deprecated for many years
now, and is unlikely to be pertinent to most readers.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
This function type isn't only used by g_hash_table_foreach_remove(), and
what happens to the data when we return TRUE depends on the calling
function.
Includes a port to modern gi-docgen syntax by Emmanuele Bassi.
Signed-off-by: Adrien Plazas <adrien.plazas@codethink.co.uk>
When listing schemas from a specified directory, explicitly
create the GSettings object from the schema, don't allow g_settings_new
to do the usual lookup. That lookup fails if no other schemas are
installed in the default directories.
Fixes#3429.
This can never have been tested, it was returning `GUnixMountEntry`
structs from functions which are typed to return `GUnixMountPoint`s.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
While GLib doesn’t parse these files, it does provide API to access the
fields from them, and does implement some logic based on options fields
in them. It would be nice to be able to test that, and get coverage of
the methods for `GUnixMountPoint` and `GUnixMountEntry`.
We don’t expect users to start querying the fstab or mtab by explicitly
loading data from those file paths. These functions are mainly intended
to prove a controllable entry point into the `gunixmounts.c` code for
unit testing.
It means we can provide a file with controllable contents in order to
test the mount entry/point code on.
See: https://gitlab.gnome.org/GNOME/glib/-/merge_requests/4155
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
You may not always know which schemes are available.
The library should not bail out, but only show
an informal message. It's the responsibility of
the application to deal with invalid URI schemes.
The test brings a Finder window to the front. It's not ideal,
but I have no better idea at the moment. It would be cool if we
can make the test case register itself as handler for a particular
uri scheme, but I have no idea how to do that.
GHashTable optimizes for the "set" case, where key and value are the same.
See g_hash_table_add().
A user cannot see from outside, whether a GHashTable internally is a set
and shares the keys and values array. Adding one key/value pair with
differing key and value, will expand the GHashTable.
In all other cases, the GHashTable API hides this implementation detail
correctly. Except with g_hash_table_steal_extended(), when stealing both the
key and the value.
Fix that. This bug fix is obviously a change in behavior. In practice,
it's unlikely that somebody would notice, because GHashTable contains
opaque pointers and the user must know what the keys/values are and
be aware of their ownership semantics when stealing them. That means,
the change in behavior only affects instances that are internally a set,
of what the user most likely is aware and fills the table with
g_hash_table_add(). Such a user would not steal both the key and
values at the same time. Even if they do, then previously stealing the
value was pointless and would not give them what they wanted. It would
not have meaningfully worked, and since nobody reported a bug about this
yet, it's unlikely somebody noticed.
The more problematic case when the user exhibits the bug is when the
dictionary is unexpected a set internally. Imagine a mapping from numbers
to numbers (e.g. a permutation). If "unexpectedly" the dictionary contains
the identity permutation, steal-extended gives always NULL for the target
number.
The example is far fetched. In practice, it's unlikely that somebody is
gonna notice either way. That is not an argument for fixing anything.
The argument for fixing this, is that the bug breaks the illusion that
the set is only an internal optimization. That is ugly and inconsistent.
