These are here to prevent linker errors, since `gcontenttype.[ch]`
aren’t compiled on Windows or macOS.
The implementations are stubs to be filled out by someone who knows each
platform, at some point in the future.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Fixes: #1791
We're using the `install` argument for configure_file() all over the
place.
The support for an `install` argument for configure_file() was added in
Meson 0.50, but we haven't bumped the minimum version of Meson we
require, yet; which means we're getting compatibility warnings when
using recent versions of Meson, and undefined behaviour when using older
versions.
The configure_file() object defaults to `install: false`, unless an
install directory is used. This means that all instances of an `install`
argument with an explicit `true` or `false` value can be removed,
whereas all instances of `install` with a value determined from a
configuration option must be turned into an explicit conditional.
We want to use the keyfile backend in sandboxes,
but we want to avoid people losing their existing
settings that are stored in dconf. Flatpak does
a migration from dconf to keyfile, but only if
the app explictly requests it.
From an app perspective, there are two steps to
the dconf->keyfile migration:
1. Request that flatpak do the migration, by adding
the migrate-path key to the metadata
2. Stop adding the 'dconf hole' to the sandbox
To keep us from switching to the keyfile backend
prematurely, look at whether the app has stopped
requesting a 'dconf hole' in the sandbox.
The plugin modules in these tests get statically linked with a separate
copy of GLib so they end up calling vfuncs in their own copy of GLib.
Fixes#1648
v7, based on a patch by mrgard (GNOME/glib#1635)
make w32_adapter_ipv4_addr() C90-compliant
check for ERROR_BUFFER_OVERFLOW when calling GetAdaptersAddresses()
code-style fixes
indentation fixes
use g_try_(re)alloc and g_free
style suggestions by pwithnall
drop uni_count variable
cap maximum allowed interface name string length according to windows documentation
Fixes: #1635
We need to enable building the dirent and gnulib sources for clang-cl,
as we are still using the Microsoft-style headers and lib's and CRT.
We need to also do this for the following, for similar reasoning:
-Symbol export (via __declspec(dllexport))
-Dependency discovery without pkg-config files
-long long and ssize_t detection
We do, however, enable the autoptr tests for clang-cl builds. Note that
at this point real MSVC builds are still better supported than clang-cl
builds, and it will likely remain so for at least the near future,
alhtough real MSVC builds of the GTK stack are consumable and are usable
by clang-cl.
In _g_object_unref_and_wait_weak_notify() we take a weak reference and
then call g_object_unref() in an idle callback, which may look like
we're dropping a strong reference without having one. So change the
comment to make it more clear that the reference being dropped is held
by the caller.
Now that we're not calling g_object_run_dispose() indirectly in
g_test_dbus_down() (see commit "Revert "gtestdbus: Properly close server
connections""), the test gdbus-connection-loss is failing with the
message "Bail out! GLib-GIO-FATAL-WARNING: Weak notify timeout, object
ref_count=1". This is because we're holding a reference to the singleton
connection object while calling session_bus_down() in the test's main().
So then we end up waiting for 30 seconds in
_g_object_unref_and_wait_weak_notify() for the GWeakNotify to be
triggered, which never happens.
The fix is to unref the connection before calling session_bus_down().
This is consistent with how other tests work, and is safe because the
only method called on the connection has already errored out, as
asserted by the test.
This reverts commit c37cd19fee.
Now that we've reverted the commit "gtestdbus: Properly close server
connections", g_test_dbus_down() no longer returns early and we no
longer need this workaround. Since the gdbus-names test seems to
properly unref its GDBusConnection objects it's not clear to me why it
needed the sleep to succeed. However even at the time the failure wasn't
reproducible according to this comment[1] so it's probably not worth
spending more effort trying to reproduce it now.
[1] https://gitlab.gnome.org/GNOME/glib/issues/787#note_214235
This reverts commit baf92d09d6.
Closes#787
According to the original commit, this change was made because otherwise
g_test_dbus_down() following a g_test_dbus_stop() hangs until it times
out. The timeout being referred to is the 30 seconds which are waited by
_g_object_unref_and_wait_weak_notify() for the GWeakNotify to be
triggered when the last strong reference to the singleton
GDBusConnection object is dropped. But the patch was not correct and the
leak should have instead been fixed by having the last strong reference
holder drop their reference on the GDBusConnection before calling
g_test_dbus_down(). Timing out after 30 seconds is the desired behavior
in the case where someone holds a reference to the singleton for that
entire period.
There are a few problems with this patch. First, as pointed out here[1],
calling g_object_run_dispose() in the idle callback means we are causing
the GWeakNotify to trigger ~immediately rather than waiting 30 seconds
to give another owner a chance to unref. Second, since someone else may
still hold a reference on the object being disposed, they may call
methods on it after it's been disposed which can seg fault as documented
here[2] and as I also saw recently in another project.
It's unclear what the original leak being fixed was, but many have been
fixed between 2013 and now. I ran all the unit tests under valgrind, and
some do fail (some consistently and some intermittently) but none of the
failures seem to only happen after this reversion commit. I also
couldn't find anywhere in the valgrind output where any GDBusConnection
objects are definitely being lost.
[1] https://gitlab.gnome.org/GNOME/glib/issues/787#note_214226
[2] https://gitlab.gnome.org/GNOME/glib/issues/787#note_214237
For several years now (I haven’t looked up the exact date),
`gnome-terminal` has preferred being called as `gnome-terminal
--terminal-args -- /some/other/program --its-args` rather than as
`gnome-terminal --terminal-args -x /some/other/program --its-args`.
Since 2017 it has warned about uses of `-x` (see
ad4edbd118).
So we should change our calling convention for it.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
There seems to be no reason to do so, and since the `appinfo` test was
ported to use `G_TEST_OPTION_ISOLATE_DIRS`, it has been causing
coredumps to accumulate. `gnome-terminal` was chosen as the terminal,
but it couldn’t find its GSettings schemas due to all the XDG
environment variables being cleared to `/dev/null` by
`G_TEST_OPTION_ISOLATE_DIRS`.
In order to keep using `gnome-terminal` as a subprocess in the tests,
we’d need to explicitly set up its environment so it can load the right
GSettings schemas. That’s a lot of work for not much gain.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Helps: #436
This commit changes a comment in _g_dbus_worker_do_read_cb() to be
slightly more useful. At least in my experience debugging an
intermittent unit test failure in another project, this failure
condition occurred because although g_test_dbus_down() ensures that the
session GDBusConnection has exit-on-close set to FALSE before killing
its dbus-daemon, there was still a GDBusConnection on the system bus
which hit this failed read code path, because we had
DBUS_SYSTEM_BUS_ADDRESS set to the address of the #GTestDBus daemon, to
appease libudisks.
Also, make a few other minor improvements to the docs.
On Visual Studio, Meson builds modules as xxxx.dll, not libxxxx.dll when
xxxx is specified as the name for the shared_module() build directive.
This means that in the test programs if we expect for libxxxx for the
module name, the test will fail as there is no libxxxx.dll but there is
xxxx.dll. This makes the test program look for the module files
correctly.
This makes use of the string we now have from glib-private.h in the
last commit so that setlocale() sets the default system locale
correctly and therefore show the translated messages properly.
Fixes issue #1169.
Using the generic marshaller has drawbacks beyond performance. One such
drawback is that it breaks the stack unwinding from the Linux kernel due
to having unsufficient data to walk past ffi_call_unixt64. That means that
performance profiling by application developers looks grouped among
seemingly unrelated code paths.
While we can't fix the kernel unwinding here, we can provide proper
c_marshallers and va_marshallers for objects within Gio so that
performance profiling of applications is more reliable.
Related to GNOME/Initiatives#10
If c_marshaller is provided during g_signal_new() registration, the
automatic va_marshaller will not be set. If we leave the c_marshaller as
NULL in the simple cases, both a c_marshaller and va_marshaller will be
set for us.
This is particularly helpful when dealing with stack traces from Linux
perf, which often cannot unwind the stack beyond the ffi_call_unix64
stack-frame on x86_64.
Related to GNOME/Initiatives#10
This ensures that D-Bus connections established with unix:dir and
unix:path addresses actually work properly. Previously, we only tested
unix:tmpdir and TCP addresses.
This is not going to have much any effect currently since stop() just
disconnects a signal handler (that is going to be disconnected in
finalize anyway) and stops the socket service (that is going to be
destroyed in finalize), but it makes sense to do here for robustness.
unix:dir= addresses are exactly the same as unix:tmpdir= addresses,
already supported by GDBus, except they forbid use of abstract sockets.
This is convenient for situations where abstract sockets are
impermissible, such as when a D-Bus client inside a network namespace
needs to connect to a server running in a different network namespace.
An abstract socket cannot be shared between two processes in different
network namespaces.
Applications could use unix:path= addresses instead, so this is only a
convenience, but there's no good reason not to support unix:dir=.
Currently it is not supported simply because unix:dir= is a relatively
recent addition to the D-Bus spec.
It's somewhat unrealistic to use a GDBusServer without a
GDBusAuthObserver, because most D-Bus servers want to be like the
standard session bus (the owning user can connect) rather than being
like the standard system bus (all users can connect, the server is a
security boundary, and many bugs are security vulnerabilities).
Signed-off-by: Simon McVittie <smcv@collabora.com>
This is simpler and more robust than DBUS_COOKIE_SHA1, which relies
on assumptions about random numbers and a secure home directory.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Authentication is about proving who I am; authorization is about
whether, given the knowledge of who I am, I am allowed to do something.
GDBusServer and GDBusConnection carry out authentication automatically,
but rely on the library user to carry out authorization.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This is useful information for implementors of portable software to know
whether they can rely on credentials-passing.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Previously, its tests were being run in the build directory, which is
fine (it should always be writable). If multiple tests were run in
parallel, for example with Meson’s `--repeat` option, their test files
would collide.
Fix that by running each test instance in a separate subdirectory of
`/tmp`.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Helps: #1634
Add a case for when the IPv6 result comes back negative and the IPv4
result is significantly delayed. This is exactly the case that causes
the bug addressed by GNOME/glib!865
The "happy eyeballs" RFC states that on receiving a negative response
for an IPv6 address lookup, we should wait for the IPv4 lookup to
complete and use any results we get from there.
The current code was not doing that: it was rather setting a timeout for
failing the resolution entirely. In scenarios where the IPv4 response
comes more than 50ms after the IPv6 response (which is easily attainable
under valgrind in certain configurations) this means that the IPv4
response will never come.
Remove the timeout and just wait.
See merge request GNOME/glib!865
It should produce a generic result, but not crash. It was previously
crashing on macOS.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Fixes: #1729
g_assert_*() give more helpful error messages on failure, and aren’t
compiled out by G_DISABLE_ASSERT.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
This was introduced in commit 7846d6154a: g_subprocess_get_identifier()
will return NULL after the subprocess has exited, and the subprocess in
the `noop` test will exit as soon as it has started spawning. So if the
scheduler scheduled the testprog subprocess quickly, descheduled the
parent test process until the testprog exited, then the return value
from g_subprocess_get_identifier() would be NULL.
Move the g_subprocess_get_identifier() test to one which calls testprog
in `sleep-forever` mode, since that is guaranteed not to exit until
killed (which we do later in the test).
Signed-off-by: Philip Withnall <withnall@endlessm.com>
The most useful ones were already listed in the pkg-config file, but
some others (notably, `gio-querymodules`) were not. List them in the
pkg-config file with their installed paths so that the right binary is
used if GIO is installed in a non-default path.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Fixes: #1796
`NM_STATE_CONNECTED_SITE` is documented to mean that a default route is
available, but that the internet connectivity check failed. A default
route being available is compatible with the documentation for
GNetworkMonitor:network-available, which should be true if the system
has a default route for at least one of IPv4 and IPv6.
https://developer.gnome.org/NetworkManager/stable/nm-dbus-types.html
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Fixes: #1788
More vectors will give an error and we can simply clamp here and
consider it like a short write instead.
In case of GSocketOutputStream this is done here instead of inside
GSocket before calling sendmsg() because we we can't generically handle
short writes when sending messages on a socket, e.g. for datagram
sockets this causes only part of the datagram to be sent and an error
would be more useful in this case than sending corrupted data.
Also reduce the fallback limit to 16 in gsocket.c as that's the minimum
value required by POSIX and add a static assertion that the limit is
never bigger than G_MAXINT as that's the type recvmmsg/sendmmsg take.
These have all been documented as deprecated for a long time, but we’ve
never had a way to programmatically mark them as deprecated. Do that
now.
This is based on the list of deprecations from the reverted commit
80fcb1bc2.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Fixes: #638
This code uses, or tests, deprecated functions, types or macros; so
needs to be compiled with deprecation warnings disabled.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
When defining deprecated macros, annotate them with
`GLIB_DEPRECATED_MACRO_IN_*()` and `GLIB_DEPRECATED_MACRO_IN_*_FOR()` to
conditionally emit warnings if people use them, depending on their
declared minimum and maximum GLib version requirements (see
`GLIB_VERSION_MIN_REQUIRED` and `GLIB_VERSION_MAX_ALLOWED`).
The old way of doing this was for users to define `G_DISABLE_DEPRECATED`
if they didn’t want to use deprecated APIs, but it reported errors via
missing symbols, and wasn’t version-dependent. It’s being phased out.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
