Now that we're using TAP parsing, this will show subtest failures in
details but without showing any logging error, that we'd still need to parse
from actual logs.
When we've a failure our TAP reporting just bails out without that is clear
what is the test that has failed.
So in this case, expose a "not ok" message if the test name is known, and
use it to report the error message too if available.
Otherwise just use the same Bail out! strategy.
This is something that a base test should decide, so if a subtest fails it's
up to the caller to decide whether to bail out the whole suite or just the
subtest.
When using verbose logging, all the printing and the glib info and debug
logs may end up being written in standard out, making meson TAP parser to be
confused and to fail with TAP parsing errors.
So, in such case write the subprocess output all at once using the the gtest
printer so that we add proper formatting.
Also do not write any gtest result message for subprocesses
When using TAP output in gtest, all the printed strings should be commented
not to break the spec, so enforce this at GTest level, by ensuring that
all the lines written via g_print() will be in the commented form and will
respect the subtest indentation.
As per this we can remove some custom code in g_test_log() as now there are
very few cases in which we need to use the default print handler which is
now private when testing.
g_set_print_handler() and g_set_printerr_handler() are supposed to return
the old printer handlers, but in case the default is used NULL is returned
instead.
This makes hard to override the default handler to e.g. decorate the output
with some minor content, without having to rewrite the low-level
implementation.
So, make the default printers to be functions and set them as the default
ones. Also this avoids having to check each time what function to use at
print time.
While checking the validity of a `GVariantTypeInfo` is good, this code
path is very hot, and I’ve never seen these assertions catch a bug in
practice.
Lean more towards the performance side of the performance/correctness
tradeoff in this case, by removing the assertions here.
They remain in place in a number of other `GVariantTypeInfo` code paths,
so invalid `GVariantTypeInfo` pointers should hopefully still be caught
quickly.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
These functions were previously calling
`g_variant_serialised_n_children()` twice just to validate the input, in
the case that the input was a serialised variant.
That’s not necessary, and checking the number of children in a
serialised variant is not necessarily cheap.
Move the checks around so that the number of children is only checked
once on each code path. This doesn’t introduce any functional changes.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
As with commit 9ae59bd647, deeply nested
maybes in an array can be exploited by a malicious caller to cause a
geometric increase in processing time and number of `GVariant` instances
handled by the `g_variant_print()` code.
Optimise this by skipping recursing through most of the chain of maybes,
thus avoiding all the setup checks in each recursive call.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
oss-fuzz#54577
Only use g_test_log() because it will prepend `#` to log messages when
using TAP protocol. Meson >=1.0 rightfully prints a warning when using
TAP protocol and stdout contains non-comment unknown TAP command.
Sadly meson 60 doesn't support parsing TAP 14 subtests properly, so it would
fail.
So temporary go back to the previous logic in a simple way so that this
commit can be reverted quickly when we can use a newer meson version.
Instead of just commenting all the output of sub-processes we can just use
the TAP 14 syntax for subtests, by using 4-spaces to indent the subtests
output.
This may not work perfectly when there are sub-process that may write
output mixed with the parent, but it should be enough to expose the
hierarchy.
If a gtest process is run as a child of another process, we should not print
the TAP output in plain mode or we'll break the parent results.
We can instead just comment their output so that it gets ignored by TAP
parsers.
Extra lines must be prepended with `#` which g_test_message() does for
us. Note that lines after "Bail out" are ignored, so we print
stdout/stderr before.
Do not write it in multiple lines, to ensure it's going to be written
all together, and nothing else could be written in the middle.
Also optimize a bit the code.
We used to send the test log to stderr in pieces, but this could be
problematic when running multiple tests in parallel, so let's just prepare
the string in pieces and write it all at once.
In some cases if verbose output was enabled we were using wrong output
format in TAP mode, so let's fix these cases and run the 'testing' test
case in --verbose mode to ensure we won't regress.
When running multiple tests in parallel using meson, the output could be
mixed and if we write the TAP reports in multiple steps the output could
be mangled together with other results.
An example is: https://gitlab.gnome.org/3v1n0/glib/-/jobs/2507620
Where we have:
ok 5 /cancellable/poll-fd# GLib-GIO-DEBUG: Collecting capable appnames: 0ms
# Allocating hashtables:...... 0ms
# Reading capable apps: 63ms
# Reading URL associations:... 0ms
# Reading extension assocs: 78ms
# Reading exe-only apps:...... 47ms
# Reading classes: 312ms
# Reading UWP apps: 47ms
# Postprocessing:..............16ms
# TOTAL: 563ms
# SKIP Platform not supported
Leading to a clear TAP parsing error
This is not required, but meson may warn about in future versions, so it's
safer to define it.
However, we must be sure that we only expose it once and in the root binary
if a test file launches another subprocess test file.
To avoid this, we set an environment variable at test init, so that it can
be inherited by children.
It's not the best solution, but for sure the best-effort one without having
to change gtest arguments and called binaries.
Non mentioning a version was considered as assuming we were using TAP
version 12, while no version earlier than 13 can be specified
explicitly so let's use it.
See: https://testanything.org/tap-specification.html
And: https://testanything.org/tap-version-13-specification.html
As per meson default, the project name is a suite per se that is always
added to a test, so running `meson test --suite=glib` is the same as not
passing the `--suite` argument at all, and so making all the tests to run.
To be able to only run the *glib* tests without using the `--no-suite` args,
add a `core` suite that only targets the glib folder tests.
In all these cases we don't really care about running the test file,
while building and basic execution it is relevant.
Also they don't support TAP at all.
Meson supports tap protocol results parsing, allowing us to track better
the tests that are running (and the ones that are actually skipped) without
manually parsing the test output.
However this also implies that using the verbose mode for a test doesn't
show its output by default (unless there are failures).
Setting the main thread's scheduler settings is not reliably possible,
especially not if SELinux or similar mechanisms are used to limit what
can be done.
As such, get rid of all the complicated code that tried to do this
better and use a separate thread for spawning threads for the global
shared thread pool. These will always inherit the priority of the main
thread (or rather the thread that created the first shared thread pool).
Fixes https://gitlab.gnome.org/GNOME/glib/-/issues/2769
g_print(), g_printerr() and all the g_log() functions used to always
duplicating a string when printing even if there's nothing to format.
This can be avoided in many cases though, so if a string has no formatting
directive, we can just write it as it is without duplicating and free'ing
it.
From my tests the potential `strchr` overhead is minimal.
To try and debug why the following assert sometimes fails on
`msys2-clang64`, such as in this job:
https://gitlab.gnome.org/GNOME/glib/-/jobs/2515166.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #1371
