Rather than tracking them with a counter. This should close the race in
tracking the finalisation of the tasks by the task worker thread.
There’s no way to synchronise with that thread as it’s internal to
`g_task_run_in_thread()`.
This should hopefully stop the `debugcontroller` test being flaky.
See https://gitlab.gnome.org/GNOME/glib/-/merge_requests/2486#note_1384102
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
It’s only used if building for lldb. Spotted in the log from an oss-fuzz
build:
https://oss-fuzz-build-logs.storage.googleapis.com/log-051f05da-adf5-42c1-8f14-5e36ba750573.txt:
```
Step #12 - "compile-honggfuzz-address-x86_64": [36/1232] Compiling C object glib/libglib-2.0.a.p/gbacktrace.c.o
Step #12 - "compile-honggfuzz-address-x86_64": ../../src/glib/glib/gbacktrace.c:324:24: warning: variable 'line_idx' set but not used [-Wunused-but-set-variable]
Step #12 - "compile-honggfuzz-address-x86_64": int sel, idx, state, line_idx;
Step #12 - "compile-honggfuzz-address-x86_64": ^
Step #12 - "compile-honggfuzz-address-x86_64": 1 warning generated.
```
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
We’re trying to eliminate the legacy `tests/` directory. This commit
moves the code from `tests/iochannel-test.c` into
`glib/tests/io-channel.c` and ports it to the latest GLib test coding
standards:
* Change `g_assert()` to `g_assert_*()`
* Print verbose messages with `g_test_message()`
* Rename some variables to conform to modern conventions
* Use `GTest`
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #1434
We are matching `<parameter>` as well as `<para>`, and we
end up with broken XML in case the (expanded) description
starts with `<parameter>`.
Fixes: #2601
We can't exercise precondition check failures if GLib was (inadvisably)
compiled with -Dglib_checks=false, and we shouldn't necessarily exercise
precondition check failures when using QA tools like valgrind, so skip
these tests if run with -m no-undefined.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Previously, these tests would always pass. If the precondition check
failed (as we want it to), the subprocess would exit unsuccessfully;
but if the precondition check wrongly passed, the subprocess would
continue, allocate a nonzero amount of memory, and fail the
g_assert_null(), resulting in the subprocess exiting unsuccessfully
and the test still passing.
Signed-off-by: Simon McVittie <smcv@collabora.com>
On ILP32 platforms, 4 is a valid alignment for g_aligned_alloc(), so
use 2 as our invalid alignment instead.
Signed-off-by: Simon McVittie <smcv@collabora.com>
