This should hopefully stop the kernel spending a lot of memory and disk
bandwidth creating coredumps for them unnecessarily, which slows down
the rest of the tests and generally wastes resources.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2939
This is put together through git archaeology:
```
git log -- glib/tests/assert-msg-test.c tests/assert-msg-test.c
```
The following commits were too trivial to have meaningful copyright:
- 8e59d8602ca5921d78245f5d2b405b517a5e7cf9
- 44c004c84e9080040ff4e0e90b322dda0561cf85
- 207b8cb8a50d68e207d28b59e588311a5cbd9772
- a1bee97d4f093db01dee834bf3292eabd5b13d17
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #1415
Apparently 3 hashes is too many, and as a result this line is not
displayed properly in the HTML documentation. 2 hashes seems to be
just right, as can be seen with:
$ git grep '^ \* ##' | wc -l
65
$ git grep '^ \* ###' | wc -l
1
Otherwise it might look like it would only start spawning threads when
jobs are enqueued.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2958
If you’re only quickly looking at the API signature, it looks like
`item_free_func` will be called for all items enqueued to the thread
pool.
As it happens, it’s actually only called for the items which are still
enqueued when the thread pool is destroyed. The user’s `GFunc` is
responsible for freeing items which are successfully dequeued and
processed during the lifetime of the thread pool.
That’s a bit of a gotcha, so document it more explicitly.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
If both __NR_futex and __NR_futex_time64 are defined, g_futex_simple()
will first call futex_time64(). If that fails with ENOSYS, then
futex_time() is called instead. However, errno was not saved and
restored in this case, which would result in g_futex_simple()
returning with errno set to ENOSYS, even if futex_time() succeeded.
As with the previous commit.
The logic has to be a little contorted here to avoid leaving the context
locked after emitting the critical warning. Execution does (and should)
continue after a critical warning by default, so we should do our best
to recover.
Inspired by https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3302.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
The documentation was fairly clear before, but we can make it clearer:
it’s a programming error to call `g_main_context_release()` if you have
not received a true return value from `g_main_context_acquire()` before.
Inspired by https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3302.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
We need a way to initialise refcounted types placed in static storage,
or on the stack. Using proper macros avoids knowing the magic constant
used for grefcount and gatomicrefcount.
In non-perf mode, we were making only one thread to win the race to increase
the value, but since we're launching more threads anyways let's allow
more of them to have a chance to do something, to make the test more
valuable, even if it's still quick enough.
This removes the `comment` member of the GKeyFileGroup structure, which
seemed intended to distinguish comments just above a group from comments
above them, separated by one or more blank lines. Indeed:
* This does not seem to match any specification in the documentation,
where blank lines and lines starting with `#` are indiscriminately
considered comments. In particular, no distinction is made between the
comment above the first group and the comment at the beginning of the
file.
* This distinction was only half implemented, resulting in confusion
between comment above a group and comment at the end of the preceding
group.
Instead, the same logic is used for groups as for keys: the comment
above a group is simply the sequence of key-value pairs of the preceding
group where the key is null, starting from the bottom.
The addition of a blank line above groups when writing, involved in
bugs #104 and #2927, is kept, but:
* It is now added as a comment as soon as the group is added (since a
blank line is considered a comment), so that
`g_key_file_get_comment()` returns the correct result right away.
* It is always added if comments are not kept.
* Otherwise it is only added if the group is newly created (not present
in the original data), in order to really keep comments (existing and
not existing).
Closes: #104, #2927
Even though having NULL as nullptr should be the standard for newer C++
versions, it may break some headers, so let's not touch it for now.
Closes: https://gitlab.gnome.org/GNOME/glib/-/issues/2973
A context iteration we're doing lots of lock/unlocks and that's fine to give
other threads contexts a chance to run, but we're doing it also just to call
other functions that require locking, and this can be avoided.
Other threads can still have a chance to run while releasing the ownership
of the context.
In practice, this will never happen.
If `getcwd()` returns `ERANGE` whenever the working directory is ≥
`PATH_MAX`, though, the previous implementation of the loop would run
until `max_len == G_MAXULONG`, and would then overflow when adding `1`
to it for a nul terminator in the allocation.
Avoid that problem by always keeping `buffer_len` as a power of two, and
relying on `getcwd()` to write a nul terminator within the buffer space
it’s given. It seems to do this on all platforms we care about, because
the previous version of the code never explicitly wrote a nul terminator
anywhere.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #98
Various projects are running tests under valgrind, and they are using
the GLib suppresions to avoid false-positive results.
While this is stored in a well-known path for some years, and easy to
figure out from the GLib prefix, it's better to expose it through a
proper pkgconfig variable so that it's easy to get it from any build
system.
We were working around that with a call to chdir("."). Internally chdir()
sets up cmd shell-related environment variables, but only if the current
working directory belongs to a volume with a drive letter. For example,
if the current working directory is on a UNC volume like a network share,
the call to chdir() won't help.
Reference:
https://developercommunity.visualstudio.com/t/UCRT-Crash-in-_wspawne-functions/10262748
Add three classes of test case for which g_utf8_normalize() should
safely return NULL:
- Strings ending with a truncated multibyte character which would
extend past the NUL terminator
- Strings ending with a multibyte character which extends past the
length limit provided by the max_len argument
- Strings containing an invalid multibyte character in any position
_g_utf8_normalize_wc() could read past the end of the provided buffer if
it ends with a truncated multibyte character. If max_len is -1, it can
continue reading until it encounters either a NUL or unreadable
memory. Avoid this with extra bounds checks prior to g_utf8_get_char()
to ensure that it does not read past either max_len or a NUL
terminator.
