This avoids a critical warning from trying to disconnect a signal
handler from a `NULL` object if `paction->object` is `NULL` for whatever
reason (see: the following commit).
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #3130
I had thought that because `g_source_destroy()` was called for the two
sources (cancel and timeout) in the `GTask` finalize function for a
threaded resolver operation, that it would be fine to use a plain
pointer in the source callbacks to point to the `GTask`.
That turns out to not be true: because the source callbacks are executed
in the GLib worker thread, and the `GTask` can be finalized in another
thread, it’s possible for a source callback (e.g. `cancelled_cb()`) to
be scheduled in the worker thread, then for the `GTask` to be finalized,
and then the source callback to continue execution and find itself
doing a use-after-free.
Fix that by using a weak ref to the `GTask` in the source callbacks,
rather than a plain pointer.
Signed-off-by: Philip Withnall <philip@tecnocode.co.uk>
Fixes: #3105
The fields are fully validated in `validate_headers()` in
`gdbusmessage.c` now, so the connection code should be able to rely on
the required ones being non-`NULL`.
Signed-off-by: Philip Withnall <philip@tecnocode.co.uk>
Helps: #3061
`object_path` and `path` were doing exactly the same thing here.
This introduces no functional changes.
Signed-off-by: Philip Withnall <philip@tecnocode.co.uk>
We already validated that the required headers for each type of D-Bus
message were present. However, we didn’t validate that they contained a
variant of the right type. This could lead to functions like
`g_dbus_message_get_path()` returning `NULL` unexpectedly.
This failure could only be hit when using GDBus in peer-to-peer mode, or
with a D-Bus server which didn’t validate the headers itself. The
reference D-Bus server does validate the headers, and doesn’t forward
invalid messages to clients.
Signed-off-by: Philip Withnall <philip@tecnocode.co.uk>
Fixes: #3061
Add test cases that result in lookup of the port via
getservbyname().
As the result depends on "/etc/services", it's not reliably the same on
every system. It requires a workaround.
Commit cf55c31170 added a new test which
uses `ptrace()` to check some `GSubprocess` behaviour. FreeBSD uses
different symbol names for ptrace symbols, and we haven’t tested whether
the test works (and reproduces the failure) on FreeBSD, so skip the test
for now.
Signed-off-by: Philip Withnall <philip@tecnocode.co.uk>
The tooling won’t pick them up unless they’re directly above the gettext
calls.
Spotted by Piotr Drąg in
ec03755355 (note_1808152).
Signed-off-by: Philip Withnall <philip@tecnocode.co.uk>
The test case will fail with the
g_assert_false (g_subprocess_get_successful (proc));
assert failing. Without the fix, it'll hit sometimes, but rather
unreliably. When running `meson test --repeat 100`, it'll reproduce
anywhere between the first or much later, but mostly before the 20th
iteration on my system.
Helps: #3071
It's not safe to use setlocale() to mutate the locale in a threaded
program. Lots of other tests still do this, and I'm not putting in the
effort to fix them comprehensively in the absense of actual failures on
CI, but I figured it'd be good to fix the tests that I was touching.
This definitely does not do anything on Linux. I bet it's not needed on
other platforms, either. It's unsafe and may crash; there is no safe way
to mutate the environment in threaded programs.
This is a copy of the existing test_l10n, modified to use LC_TIME
instead of LC_MESSAGES. It's not safe as each call to g_setenv() or
setlocale() could cause the test to crash; there is no safe way to
change a threaded process's environment, and a threaded process's locale
can only be safely changed using uselocale(), not with setlocale().
The calls to g_setenv() are definitely not needed on Linux. I wonder
whether removing these will break the test on other platforms?
The calls to setlocale() should be replaced by a dance of
uselocale() -> duplocale() -> newlocale() -> uselocale() on Linux. But
this is not portable and this is a cross-platform test. We would have to
make the test platform-specific to do this. macOS and at least FreeBSD
provide these functions via xlocale.h, but this isn't portable.
It's supposed to be possible to translate settings values using LC_TIME
rather than LC_MESSAGES to determine which translation to use, but
Sebastian Keller noticed that it's not working properly. I've
implemented his proposed solution, which is to actually temporarily
change LC_MESSAGES to match LC_TIME for just as long as necessary to
force gettext to use the desired message catalog.
Fixes#2575
Fix typo in gio/gappinfo (duplicated word)
Fix typo in gio/gtlsdatabase.c (duplicated word)
Fix typo in gio/gapplication.c (duplicated word, previous words rearranged to improve readability)
Fix typo in glib/tests/gvariant.c (duplicated word)
Fix typo in glib/win_iconv.c (duplicated word)
Fix typo in gio/gschema.dtd (meaning, missing letter)
Fix typo in gio/gdbusintrospection.c (duplicated word)
Fix typo in gio/gdbusintrospection.c (duplicated word).
I made the kqueue failure 100% reliable with `samu -j1` on FreeBSD,
and therefore confirmed this fixes that problem. Issue #2929 is
an identical failure on win32, so I assume this fixes that, too,
but I haven't confirmed.
Fixes: #2929
Following Emmanuele's instructions for use of introspection annotations:
https://www.bassi.io/articles/2023/02/20/bindable-api-2023/
I have audited all uses of the (closure) annotation in glib and
determined that only a handful are correct. This commit changes almost
all of our use of (closure) annotations to conform to Emmanuele's rules.
The test was passing fine when `bindir` was equal to `multiarch_bindir`,
but not when they differ.
For example, on a Debian system, `gio-querymodules` is installed to
`/usr/lib/x86_64-linux-gnu/glib-2.0/gio-querymodules` rather than
`/usr/bin/gio-querymodules` as it is on (say) Fedora.
This was causing the pkg-config tests to fail on Debian.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #3045
This reverts commit 004f48f4fc.
Per the discussion on #3356, this change was prompted by a
misunderstanding of ldflags/link_args, and it resulted in various other
packages using glib no longer getting symbols exported. This commit
restores the glib 2.76 behaviour.
Avoid generating more code than needed, so other than continuing using
the generic glib marshallers when possible, define once the custom ones
we need for each file we generate.
The marshallers are then re-used across all the interfaces defined
without duplicating the code size.
