The compiler code was full of leaks and nothing really checked on them.
While it's not a big deal per se, per the nature of it, it's still
better to ensure that memory management is well done so that there are
no problems when using it with sanitizers.
So, the source of the problems was not freeing the parser, but that
wasn't enough, more to come...
We are overriding the default g-ir-compiler for local usage, but this
is not actually happen since that's computed while parsing introspection
So generate the compiler as first thing, then in case handle the
introspection data
Almost identically to the previous commit, fix a similar latent bug in
`g_dbus_connection_export_action_group()`, which was not ready to handle
the fledgling `GActionGroupExporter` being freed early on an error
handling path.
See the previous commit message for details of the approach.
This includes a unit test.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Fixes: #3366
Fedora 37 is out of support so, as per our policy, update the CI image
to the oldest still-supported release, which is 39.
Update the mingw CI image too, as it’s built on top of the Fedora one.
Update the supported platforms documentation (and fix the Debian version
listed there to match what’s currently in CI, which is up to date).
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
This latent bug wasn’t triggered until commit 3f30ec86c (or its
cherry-pick onto `glib-2-80`, 747e3af99, which was first released in
2.80.1).
That change means that `g_menu_exporter_free()` is now called on the
registration failure path by `g_dbus_connection_register_object()`
before it returns. The caller then tries to call `g_slice_free()` on the
exporter again. The call to `g_menu_exporter_free()` tries to
dereference/free members of the exporter which it expects to be
initialised — but because this is happening in an error handling path,
they are not initialised.
If it were to get any further, the `g_slice_free()` would then be a
double-free on the exporter allocation.
Fix that by making `g_menu_exporter_free()` robust to some of the
exporter members being `NULL`, and moving some of the initialisation
code higher in `g_dbus_connection_export_menu_model()`, and removing the
duplicate free code on the error handling path.
This includes a unit test.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Fixes: #3366
gio/glocalfileinfo.c has a struct 'ThumbMD5Context'
that's been unused since
commit d013d46b98 ("Replace the copy-and-paste MD5 digest generation
with GChecksum.")
Remove it.
Signed-off-by: Dr. David Alan Gilbert <dave@treblig.org>
The type used when declaring a bitfield member of a struct doesn't
affect the amount of space allocated for it - only whether it's signed
or unsigned. In standard C99 (6.2.7.1), only _Bool, signed int and
unsigned int or typedefs to them are allowed as bitfield types, but GCC
allows other integer types as an extension.
In this case, the GIBaseInfo and GIBaseInfoStack structs are meant to
have identical layout. However, type_is_embedded was declared as an
unsigned bitfield in the former and a uint32_t in the latter. This was
harmless on most platforms because the following member is an aligned
pointer, but (for example) on m68k-linux-gnu pointers only need to be
16-bit aligned, so GCC only allocates 16 bits for the bitfield.
Change the type in the declaration to unsigned int, and add an padding
bitfield following it to ensure there's space for 32 bits on all
platforms in the future.
Signed-off-by: Adam Sampson <ats@offog.org>
GCC 14 now emits this warning with the tests:
```
In file included from ../glib/gthread.h:34,
from ../glib/gasyncqueue.h:34,
from ../glib/glib.h:34,
from ../glib/tests/atomic.c:14:
../glib/tests/atomic.c: In function 'test_types':
../glib/gatomic.h:140:5: error: argument 2 of '__atomic_store' discards 'volatile' qualifier [-Werror=discarded-qualifiers]
140 | __atomic_store (gaps_temp_atomic, &gaps_temp_newval, __ATOMIC_SEQ_CST); \
| ^~~~~~~~~~~~~~
../glib/tests/atomic.c:139:3: note: in expansion of macro 'g_atomic_pointer_set'
139 | g_atomic_pointer_set (&vp_str_vol, NULL);
| ^~~~~~~~~~~~~~~~~~~~
cc1.exe: all warnings being treated as errors
```
I can’t think of a way to cast around this in the definition of
`g_atomic_pointer_set()` without making the behaviour worse (less type
safe) for modern non-volatile atomic variables.
We would like to strongly nudge users of GLib away from declaring atomic
variables as `volatile`, so letting another compiler warning be emitted
when they do is not the end of the world. As long as it doesn’t stop old
code compiling (without `-Werror`).
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
It's an array containing the list of sanitizers in use, normally it
contains a value, but in some cases may have more than one (e.g.
'address' and 'undefined').
And so use it to avoid repeated checks
In glocalfile we're allocating some temporary strings but we don't free
them on early returns, so free them once done and unset the variables
to prevent them being used incorrectly.
It looks like that finally also valgrind notices the same leaks as
address sanitizer does. It does it more randomly but it still happens,
so better to inform about until #2309 is resolved.
Tests may have runtime dependencies that are related to the typelib
dependencies, so we need to satify them or the tests will fail at
runtime if we're not building their prerequisite for other reasons.
That's saying that the tests are currently failing when explicitly
running as standalone in meson.
Co-Authored-By: Philip Withnall <philip@tecnocode.co.uk>
When running the alternate stack tests under valgrind the stack memory
gets corrupted that we've initialized gets somehow corrupted and this
causes a read-error while reading the stack memory area.
No matter if we use instead malloc-allocated or mmap'ed memory areas,
the result is always the same: a memory error while reading it.
Reading byte 2645
Reading byte 2646
Reading byte 2647
Reading byte 2648
==46100== Invalid read of size 1
Now this memory is definitely stack-allocated and unless the valgrind
stack gets corrupted, there's no way it could have been removed.
I quite trust that this is some valgrind problem only though since no
other memory analyzer I've tried (memory sanitizer mostly) has
highlighted any issue with this.
As per this, since the main point of the test was just checking if
signals are delivered properly even when using an alternate stack, I
think that we can just safely run a simpler version of the test when
running under valgrind. This implies assuming that sigaltstack()
does what is supposed to do, without us double-checking it, but I guess
we can trust that (especially because we're still testing it when not
using valgrind).
Closes: #3337
