It was previously possible to specify the FD number which
`child_err_report_fd` was assigned, as a target FD in the FD mapping set
up using `g_subprocess_launcher_take_fd()`.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2097
This effectively moves some of the functionality of `GSubprocess`
(`g_subprocess_launcher_take_fd()`) into `g_spawn*()`, which should make
implementation a little simpler.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2097
This is an internal change which won’t affect the public API. It should
introduce no functional changes, but simplifies the code a little.
The arguments from `fork_exec_with_pipes()` have been added to
`fork_exec_with_fds()`. `child_close_fds` has been dropped since it’s
now an implementation detail within the function.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2097
Since !1715, g_atomic_pointer_get (&x) has usually returned the type of
x, rather than a generic pointer, in C++ code (where x is any pointer,
or any pointer-sized integer such as guintptr). glib/tests/cxx.cpp
asserts that this is the case.
However, this was only implemented for the lock-free fast-path, not
for the slow path used in platforms with an ARMv5 baseline (and
therefore no atomic instructions) such as Debian armel.
Signed-off-by: Simon McVittie <smcv@collabora.com>
GByteArray uses guint for storing the length of the byte array, but it
also has a constructor (g_byte_array_new_take) that takes length as a
gsize. gsize may be larger than guint (64 bits for gsize vs 32 bits
for guint). It is possible to call the function with a value greater
than G_MAXUINT, which will result in silent length truncation. This
may happen as a result of unreffing GBytes into GByteArray, so rather
be loud about it.
(Test case tweaked by Philip Withnall.)
This adds g_string_replace(), a function that replaces instances of one string
with another in a GString. It allows the caller to specify the maximum number
of replacements to perform, and returns the number of replacements performed
to the caller.
Fixes: #225
Adding test coverage indicated that this was another bug in 0cc11f74.
Fixes: 0cc11f74 "giochannel: Forbid very long line terminator strings"
Resolves: https://gitlab.gnome.org/GNOME/glib/-/issues/2323
Signed-off-by: Simon McVittie <smcv@collabora.com>
Unfortunately, `g_memdup()` accepts its size argument as a `guint`,
unlike most other functions which deal with memory sizes — they all use
`gsize`. `gsize` is 64 bits on 64-bit machines, while `guint` is only 32
bits. This can lead to a silent (with default compiler warnings)
truncation of the value provided by the caller. For large values, this
will result in the returned heap allocation being significantly smaller
than the caller expects, which will then lead to buffer overflow
reads/writes.
Any code using `g_memdup()` should immediately port to `g_memdup2()` and
check the pointer arithmetic around their call site to ensure there
aren’t other overflows.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2319
The public API `GIOChannel.line_term_len` is only a `guint`. Ensure that
nul-terminated strings passed to `g_io_channel_set_line_term()` can’t
exceed that length. Use `g_memdup2()` to avoid a warning (`g_memdup()`
is due to be deprecated), but not to avoid a bug, since it’s also
limited to `G_MAXUINT`.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2319
Convert all the call sites which use `g_memdup()`’s length argument
trivially (for example, by passing a `sizeof()` or an existing `gsize`
variable), so that they use `g_memdup2()` instead.
In almost all of these cases the use of `g_memdup()` would not have
caused problems, but it will soon be deprecated, so best port away from
it
In particular, this fixes an overflow within `g_bytes_new()`, identified
as GHSL-2021-045 by GHSL team member Kevin Backhouse.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: GHSL-2021-045
Helps: #2319
This will replace the existing `g_memdup()` function, which has an
unavoidable security flaw of taking its `byte_size` argument as a
`guint` rather than as a `gsize`. Most callers will expect it to be a
`gsize`, and may pass in large values which could silently be truncated,
resulting in an undersize allocation compared to what the caller
expects.
This could lead to a classic buffer overflow vulnerability for many
callers of `g_memdup()`.
`g_memdup2()`, in comparison, takes its `byte_size` as a `gsize`.
Spotted by Kevin Backhouse of GHSL.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: GHSL-2021-045
Helps: #2319
Various tests have leaks where it isn't clear whether the data is
intentionally not freed, or leaked due to a bug. If we mark these
tests as TODO, we can skip them under AddressSanitizer and get the
rest to pass, giving us a baseline from which to avoid regressions.
Signed-off-by: Simon McVittie <smcv@collabora.com>
AddressSanitizer detects memory leaks, NULL parameters where only a
non-NULL parameter is expected, and other suspicious behaviour, so if
we try to test that sort of thing we can expect it to fail.
Signed-off-by: Simon McVittie <smcv@collabora.com>
We preallocate buffers that are used after forked. That is because
malloc()/free() are not async-signal-safe and must not be used between
fork() and exec().
However, for the child process that exits without fork, valgrind wrongly
reports these buffers as leaked.
That can be suppressed with "--child-silent-after-fork=yes", but it is
cumbersome.
Work around by trying to allocate the buffers on the stack. At
least in the common cases where the pointers are small enough
so that we can reasonably do that.
If the buffers happen to be large, we still allocate them on the heap
and the problem still happens. Maybe we could have also allocated them
as thread_local, but currently glib doesn't use that.
[smcv: Cosmetic adjustments to address review comments from pwithnall]
For manual test coverage that would reproduce the bug fixed in !1902,
copy /bin/true (or any other harmless executable) to
/usr/bin/spawn-test-helper.
Signed-off-by: Simon McVittie <smcv@collabora.com>
do_exec() and g_execute() rely on being passed a NULL search path
if we intend to avoid searching the PATH, but since the refactoring
in commit 62ce66d4, this was never done. This resulted in some spawn
calls searching the PATH when it was not intended.
Spawn calls that go through the posix_spawn fast-path were unaffected.
The deprecated gtester utility, as used in GTK 3, relies on the
ability to run an executable from the current working directory by
omitting the G_SPAWN_SEARCH_PATH flag. This *mostly* worked, because
our fallback PATH ends with ".". However, if an executable of the
same name existed in /usr/bin or /bin, it would run that instead of the
intended test: in particular, GTK 3's build-time tests failed if
ImageMagick happens to be installed, because gtester would accidentally
run display(1) instead of testsuite/gdk/display.
Fixes: 62ce66d4 "gspawn: Don’t use getenv() in async-signal-safe context"
Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=977961
That changes the return type of functions like g_object_ref() that can
break C++ applications like Webkit. Note that it is not an ABI break.
It must thus be opt-in the same way we did when adding this to
g_object_ref() for GNU C compilers in the first place. Unfortunately it
cannot be done directly in gmacros.h because GLIB_VERSION_2_68 is not
defined there, and gversionmacros.h cannot be included there because
there is some strict ordering in which those headers must be included.
This means that applications that does not define
GLIB_VERSION_MIN_REQUIRED will still get an API break, so we encourage
them to declare their minimum requirement to avoir such issues in the
future too.
clang++ checks the 2nd args of __atomic_compare_exchange_n() has the
same type as the first, which fails when 2nd arg is nullptr which is of
type nullptr_t.
Ideally it should do `glib_typeof (*(atomic)) gapcae_oldval = (oldval);`
to ensure oldval and atomic have compatible types but unfortunately that
does not work neither.
Since that function never has been typesafe, and it is not even
attempting to use glib_typeof in case __ATOMIC_SEQ_CST is not defined,
drop it in __atomic_ case too.
Fixes issue #2226.
There are various places glib uses __typeof__ for type safety, but
that's a GNUC extension. C++11 has standard decltype() that does a
similar job, at least for cases we care about.
This avoids C++ code to always have to cast return value of
g_object_ref() which was causing type kind of error:
error: invalid conversion from ‘gpointer’ {aka ‘void*’} to
‘GstElementFactory*’ {aka ‘_GstElementFactory*’} [-fpermissive]
I found myself wanting to know the test that is currently being run,
where e.g. __func__ would be inconvenient to use, because e.g. the place
the string was needed was not in the test case function. Using __func__
also relies on the test function itself containing the whole path, while
loosing the "/" information that is part of the test path.
Since Windows 10 1607, we can make use of SetThreadDescription() API
for setting thread name. Unlike previously used exception based
method, this API will preserve configured thread name on dump file.
This makes it a little easier to link to in the generated documentation,
and separates it from the section above.
Link to the heading from the documentation for
`G_DEFINE_EXTENDED_ERROR`.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
On FreeBSD it always crashes due to the platform’s `vasprintf()`
implementation being less forgiving than Linux’s. That’s fine.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
