The source needs to be removed from the `GMainContext` before being
unreffed, otherwise the main context and main loop will be kept around.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
`g_environ_setenv()` and `g_environ_unsetenv()` were correctly returning
`NULL` when their preconditions failed (as the test is supposed to be
exercising). That overwrote the value of `env` without freeing it,
resulting in a leak.
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 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>
We only want to include gslist.h here if it was not already included via
including glib.h, as:
* gslist.h should normally be included via glib.h if used outside of
GLib itself.
* This broke Visual Studio builds that use GResources (via
glib-compile-resources.exe) as that would cause the generated code to
include gslist.h directly, which is therefore disallowed.
This can happen if a caller (ab)uses `execve()` to execute a gtest
process with an empty `argv` array. `g_test_init()` has to gracefully
handle such a situation.
Fix a few problem areas in the code, and add a simple test which checks
that `g_test_init()` doesn’t crash when called with an empty `argv`.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
While `execve()` might allow (probably malicious) users to execute a
program with an empty `argv` array, gspawn does not. It’s not actually
possible, as the path to the binary to execute is not specified
separately from the argument array.
Explicitly document and encode that in preconditions.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
It is not possible for `g_shell_parse_argv()` to return an empty `argv`
array. Make that clear in the documentation and add some assertions to
encode it explicitly in the code.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
This won’t really affect anything, but we might as well fix them to not
crash if called with an empty `argv` by someone (ab)using `execve()`.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
When working with storage (especially GInputStream or GOutputStream) it
is preferred to use page-aligned buffers so that the operating system
can do page-mapping tricks as the operation passes through the kernel.
Another use case is allocating memory used for vectorised operations,
which must be aligned to specific boundaries.
POSIX and Windows, as well as the C11 specification, provide this kind
of allocator functions, and GLib already makes use of it inside GSlice.
It would be convenient to have a public, portable wrapper that other
projects can use.
Fixes: #2574
