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
We're now caching arg0 but such value is not cleared when a new body is
set as it's in the connection filter test cases where we've a leak as
highlighted by both valgrind and leak sanitizer
In a D-Bus-Specification-compliant message bus, the owner of a well-known
name is a unique name. However, ibus has its own small implementation
of a message bus (src/ibusbus.c) in which org.freedesktop.IBus is
special-cased to also have itself as its owner (like org.freedesktop.DBus
on a standard message bus), and connects to that bus with the
G_DBUS_CONNECTION_FLAGS_MESSAGE_BUS_CONNECTION flag. The ability to do
this regressed when CVE-2024-34397 was fixed.
Relax the checks to allow the owner of a well-known name to be any valid
D-Bus name, even if it is not syntactically a unique name.
Fixes: 683b14b9 "gdbus: Track name owners for signal subscriptions"
Resolves: https://gitlab.gnome.org/GNOME/glib/-/issues/3353
Bug-Debian: https://bugs.debian.org/1070730
Bug-Debian: https://bugs.debian.org/1070736
Bug-Debian: https://bugs.debian.org/1070743
Bug-Debian: https://bugs.debian.org/1070745
Signed-off-by: Simon McVittie <smcv@debian.org>
The test case assumes signals will dispatched in a different order than
they're subscribed. In fact, signals can be dispatched in any order,
and are often dispatched in order.
This commit reorders the subscriptions so they're in order, which is
more logical, and also changes the code to only exit the event loops
when there are no pending handlers ready to dispatch.
548ec9f186 accidentally moved the GVariant
spec to the toplevel /usr/share/doc directory, which is surely not
right. Let's move it back into the glib-2.0 subdirectory.
It's debatable whether this is the best place to install the GVariant
specification, since it's not part of the gi-docgen docs, but surely
it's much better than not putting it in any subdirectory.
Fixes#3351
This was highlighted (but not introduced) by
0144feb41f. Previously the test coverage
didn’t cover this branch, I think.
`iter` was leaked, and at this point `parameter` had never been set, so
clearing it was unnecessary.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3349
GDBusConnection sends each signal to recipients in a separate idle
callback, and there's no particular guarantee about the order in which
they're scheduled or dispatched. For the NameOwnerChanged signal that
reports the name becoming unowned, it's possible that g_bus_watch_name()
gets its idle callback called before the GDBusProxy:g-name-owner
machinery has updated the name owner, in which case the assertion
will fail.
Fixing GNOME/glib#3268 introduced a new subscription to NameOwnerChanged
which can alter the order of delivery, particularly in the case where
G_DBUS_PROXY_FLAGS_NO_MATCH_RULE was used (as tested in
/gdbus/proxy/no-match-rule). The resulting test failure is intermittent,
but reliably appears within 100 repetitions of that test.
Fixes: 511c5f5b "tests: Wait for gdbus-testserver to die when killing it"
Signed-off-by: Simon McVittie <smcv@debian.org>
Some architecture such as sparc and some flavors of arm needs -latomic
to avoid the following build failure:
gthread-posix.c:(.text+0xda8): undefined reference to `__atomic_compare_exchange_4'
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
If the file to be added is on a read-only filesystem, opening read/write
will fail with EROFS. In this case we should fall back to opening it
read-only, the same way we already do if write access is forbidden by
DAC or MAC.
An easy way to reproduce this test failure is to build and test GLib
in a podman container, with its source code read-only and its build
directory read/write:
podman run --rm -it \
-v $(pwd):$(pwd):ro \
-v $(pwd)/_build:$(pwd)/_build:rw \
-w $(pwd) ...
Before this commit, the dbus-appinfo test would fail, because opening
${srcdir}/gio/tests/org.gtk.test.dbusappinfo.flatpak.desktop read/write
would fail with EROFS.
For completeness, give similar handling to the other error codes
documented in Linux open(2) that might succeed if re-attempted using
read-only access: according to that documentation, we could get EPERM
if opening read/write is prevented by fcntl F_ADD_SEALS, or ETXTBSY
if the file is an executable that is currently being run.
Signed-off-by: Simon McVittie <smcv@collabora.com>
