The past few commits introduced the concept of known-good offsets in the
offset table (which is used for variable-width arrays and tuples).
Good offsets are ones which are non-overlapping with all the previous
offsets in the table.
If a bad offset is encountered when indexing into the array or tuple,
the cached known-good offset index will not be increased. In this way,
all child variants at and beyond the first bad offset can be returned as
default values rather than dereferencing potentially invalid data.
In this case, there was no information about the fact that the indexes
between the highest known-good index and the requested one had been
checked already. That could lead to a pathological case where an offset
table with an invalid first offset is repeatedly checked in full when
trying to access higher-indexed children.
Avoid that by storing the index of the highest checked offset in the
table, as well as the index of the highest good/ordered offset.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2121
This is similar to the earlier commit which prevents child elements of a
variable-sized array from overlapping each other, but this time for
tuples. It is based heavily on ideas by William Manley.
Tuples are slightly different from variable-sized arrays in that they
contain a mixture of fixed and variable sized elements. All but one of
the variable sized elements have an entry in the frame offsets table.
This means that if we were to just check the ordering of the frame
offsets table, the variable sized elements could still overlap
interleaving fixed sized elements, which would be bad.
Therefore we have to check the elements rather than the frame offsets.
The logic of checking the elements up to the index currently being
requested, and caching the result in `ordered_offsets_up_to`, means that
the algorithmic cost implications are the same for this commit as for
variable-sized arrays: an O(N) cost for these checks is amortised out
over N accesses to O(1) per access.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2121
This reduces a few duplicate calls to `g_variant_type_info_query()` and
explains why they’re needed.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2121
If different elements of a variable sized array can overlap with each
other then we can cause a `GVariant` to normalise to a much larger type.
This commit changes the behaviour of `GVariant` with non-normal form data. If
an invalid frame offset is found all subsequent elements are given their
default value.
When retrieving an element at index `n` we scan the frame offsets up to index
`n` and if they are not in order we return an element with the default value
for that type. This guarantees that elements don't overlap with each
other. We remember the offset we've scanned up to so we don't need to
repeat this work on subsequent accesses. We skip these checks for trusted
data.
Unfortunately this makes random access of untrusted data O(n) — at least
on first access. It doesn't affect the algorithmic complexity of accessing
elements in order, such as when using the `GVariantIter` interface. Also:
the cost of validation will be amortised as the `GVariant` instance is
continued to be used.
I've implemented this with 4 different functions, 1 for each element size,
rather than looping calling `gvs_read_unaligned_le` in the hope that the
compiler will find it easy to optimise and should produce fairly tight
code.
Fixes: #2121
The following few commits will add a couple of new fields to
`GVariantSerialised`, and they should be zero-filled by default.
Try and pre-empt that a bit by zero-filling `GVariantSerialised` by
default in a few places.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2121
On some systems only `futex_time64` exists (e.g. riscv32) while on
others only `futex` exists (old Linux, 64 bit platforms), so it is
necessary to check for both and try calling both at runtime.
Additionally use the correct `struct timespec` definition. There is not
necessarily any relation between the libc's definition and the kernel's.
Specifically, the libc headers might use 64-bit `time_t` while the kernel
headers use 32-bit `__kernel_old_time_t` on certain systems.
To get around this problem we
a) check if `futex_time64` is available, which only exists on 32-bit
platforms and always uses 64-bit `time_t`.
b) otherwise (or if that returns `ENOSYS`), we call the normal `futex`
syscall with the `struct timespec` used by the kernel, which uses
`__kernel_long_t` for both its fields. We use that instead of
`__kernel_old_time_t` because it is equivalent and available in the
kernel headers for a longer time.
This reverts commit 965061797d74847d2e2d1237bb7a63328608e28c.
We are having trouble tracking down the cause of #2769. When the bug
occurs, we fail to set scheduler settings for the new thread pool
thread. This can have serious consequences and should not be ignored. In
retrospect, making this a critical instead of a fatal error has made it
more difficult to notice, debug, and fix. This operation needs to always
work, so let's crash when it fails.
This does not fix#2769, but will hopefully help.
Split g_find_program_path() in g_find_program_for_path() that supports
passing path arguments and providing a custom working directory.
Adding tests to cover the cases we were not doing before.
If the user provided source_fds set contains internal fds, this is a
programmer mistake. We can avoid further damage by preventing this
situation.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
As recommended by GDB on Fedora, I have "set debuginfod enabled on" in
my .gdbinit. However, this make assert-msg-test time out.
Let's ignore user gdbinit for the test, as this shouldn't be required
and can easily break the test.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Using `test_run_name` in the path for the isolated dir tree for a test
is fine on Unix, because the `/` separator from GTest paths is suitable
as a file system separator.
On Windows, however, it doesn‘t work when mixed and concatenated with
paths which use backslashes. In particular, byte-by-byte path
comparisons don’t work. There are likely also issues if running on a
system with non-UTF-8 file system encoding.
Fix that by storing a file system path version of `test_run_name`
separately, and using the correct `G_DIR_SEPARATOR` for the host OS.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
We have meson nowadays, so tests are timing out by default and test timeout
may vary depending on the meson test parameters or test setups.
So don't hardcode it using alarm().
The value of `wrote_bytes` will never be negative, so there’s no need to
store it in a signed type.
Add a couple of assertions to validate that it never decreases and hence
can never go negative.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
In both these cases, the static analyser (Coverity) was worrying that
the array `data`/`pdata` wasn’t allocated before an element was written
to. That was a false positive: all the necessary conditions are met in
both cases for `g_{ptr_,}array_maybe_expand()` to always allocate the
array.
But it makes things a bit easier for the analyser if we add an assertion
to double-check that.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Coverity CID: #1474426, #1489512
Further to commit bcd364afef984da894045, fix the types accepted by the
`g_str_equal()` macro for C++ too. C++ is more restrictive about
const-correctness.
Add unit tests.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2820
This reverts commit 7e3e591d430e6576292379a4f2d94d5fc0656c36.
The freedesktop SDK, which is used by gnome-build-meta, only has Meson
0.63. Bumping GLib’s Meson dependency to 0.64 means that, at the moment,
GLib is not buildable in gnome-build-meta and hence can’t be tested in
nightly pipelines against other projects, etc.
That’s bad for testing GLib.
It’s arguably bad that we’re restricted to using an older version of
Meson than shipped by Debian Testing, but that’s a separate discussion
to be had.
Revert the Meson 0.64 dependency until the freedesktop SDK ships Meson ≥
0.64. This also means reverting the simplifications to use of
`gnome.mkenum_simple()`.
See https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3077#note_1601064
This is deprecated since Meson 0.62.0, since Meson does this
automatically for us.
This fixes a Meson configure warning.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
They were mixing up `(optional)` and `(nullable)`, and didn’t correctly
annotate the arguments as `(inout)` or `(transfer full)`.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2793
We need to ensure that all the expected macros and utilities are working
with all the supported C standards, so just repeat the tests with all
the ones the compiler supports.
We defined G_NO_RETURN as [[noreturn]] in the C++ case, but only after
trying the __attribute__ syntax, so it was never used in GNUC compatible
compilers.
Give it priority instead when supporting a C++11 compiler and onwards.
As per this we need to adapt the code in the places where it was not
properly used (leading to compilation warnings).
Since it’s now always called the same way after safe_fdwalk() has been
called. This introduces no functional changes.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
This thread is created once during the process’ lifetime and cannot be
destroyed and recreated, as the thread scheduler settings might have
changed since then.
Mark the leak as explicit, mostly for documentation purposes — but it
might quieten some static analysers.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Coverity CID: #1474614
Since commit 2f9e6e977a, `count` has been used here incorrectly: after
`count_unsigned` is initialised, `count` should no longer be used as it
might be unhelpfully negative.
Fix this to correctly use `count_unsigned`.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
In `safe_closefrom()`, we thought it would be OK to assert that an FD
being closed is valid, when using `safe_fdwalk()`, as it only walks over
known-valid FDs.
However, there is a situation where that might not be true: the program
is being run under valgrind. Valgrind opens some FDs for its own use
which are ≥1024, and it emulates a lowered soft limit on FDs. So if we
were to use `safe_fdwalk_with_invalid_fds()` it would see the lowered
soft limit and not try to close valgrind’s internal FDs.
However, `safe_fdwalk()` looks at `/proc`, which valgrind does not emulate,
so it sees the secret valgrind internal FDs, and then tries to close them.
Valgrind doesn’t like this, prints ‘Warning: invalid file descriptor
1024 in syscall close()’ and returns `EBADF`. That return value
causes `g_close()` to warn about faulty FD refcounting, and that causes
unit test failures.
Fix that by relaxing our assumptions about FD validity: use
the `close_func_with_invalid_fds()` call back for closing FDs
from `safe_fdwalk()`, rather than using `close_func()`. That will
ignore `EBADF` return values.
This should fix valgrind failures like this one:
https://gitlab.gnome.org/GNOME/glib/-/jobs/2389977
Related prior art: https://bugs.freedesktop.org/show_bug.cgi?id=99839
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
The new macro form of `g_str_equal()` had stricter type checking than
the original function form. That would be nice, except it causes new
compiler warnings in third party projects, which counts as an API break
for us, so unfortunately we can’t do it.
Add some tests to prevent regressions on this again.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2809
Sadly, in C++ there's not an universal way to get what language standard
is used to compile GLib-based programs, in fact while most compilers
relies on `__cplusplus`, MSVC is defining that, but it does not use it
to expose such information (unless `/Zc:__cplusplus` arg is used).
On the other side, MSVC reports the language standard via _MSVC_LANG [1].
This complication makes us defining some macros in a very complex way
(such as glib_typeof()), because we need to perform many checks just to
understand if a C++ compiler is used and what standard is expecting.
To avoid this, define multiple macros that can be used to figure out
what C++ standard is being used.
[1] https://docs.microsoft.com/en-us/cpp/build/reference/zc-cplusplus?view=msvc-170
This should quell a scan-build error about dereferencing `member_info`
when it’s `NULL` at the end of the function, due to having zero
iterations of the `for` loop.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
This should quell some scan-build warnings about code breaking after
returning from mem_error() in a weird state.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
