It’s consistently timing out on the CI, which makes sense since it does
333 iterations of spawning a subprocess. Give it a bit more breathing
room.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
The network monitor portal interface is changing.
Version 2 is no longer using properties, but getters
instead (this lets the portal apply access control
and avoid sending information to non-networked
sandboxes).
To support both version 1 and 2 of the interface,
we stop using generated code and instead deal with
the api differences in our own code, which is not
too difficult.
Support version 1 as well
When using g_network_monitor_get_default() from another thread, it’s
possible for network-changed events to be processed after an instance of
GNetworkMonitor has been disposed, causing use-after-free problems.
Fix that by moving some of the initialisation into the GInitable.init()
chain, rather than in a main context idle callback.
This includes a unit test which probabilistically reproduces the bug
(but can’t do so deterministically due to it being a race condition).
Commit amended by Philip Withnall <withnall@endlessm.com> before
pushing.
https://bugzilla.gnome.org/show_bug.cgi?id=793727
While mountpoints are *not* symlinks, strictly speaking,
they works in a similar enough way, so consider them to be
symlinks for the purpose of querying local file info.
On Windows st_ctime field is the file creation time.
POSIX mandates that field to be the file state change time.
Naturally, glib code interpreted st_ctime as POSIX suggested,
and the result was bad.
Fix this by introducing special W32-only logic for setting
attributes from st_ctime field.
Fixes issue #1452.
Releasing GVolumeMonitor before g_volume_mount finish cause that
g_volume_get_mount returns NULL, because the mount is not correctly
propagated to the volume.
(Backported from commit 88b8ebb5dde0512fd1e098efe4c217111876d252 with
minor merge conflicts.)
https://gitlab.gnome.org/GNOME/glib/issues/1458
The documentation claims that g_volume_get_mount should succeed after
g_volume_mount. Let's update mounts before releasing g_volume_mount to
be sure that the mount is added to the corresponding volume. The same
is done in GVfsUDisks2VolumeMonitor.
(Backported from commit 9b6b282e0a9d3f37865aa36e21ea57bd2a326e20 with no
merge conflicts.)
https://gitlab.gnome.org/GNOME/glib/issues/1458
gunixmounts: Stop considering cifs/nfs as system file systems
See merge request GNOME/glib!125
(cherry picked from commit 51132b1d49c184f49baafa81ce7fac02b1458643)
a3a6c516 gunixmounts: Stop considering cifs/nfs as system file systems
The way things were before: a FreedesktopNotification struct is
allocated before the dbus call, and this same struct is possibly re-used
for other dbus calls. If the server becomes unavailable, the callback
will be invoked after the call times out, which leaves a long time where
other dbus calls can happen, re-using the same FreedesktopNotification
as user data. When the first call times out, the callback is invoked,
and the user data is freed. Subsequent calls that used the same user
data will time out later on, and try to free a pointer that was already
freed, hence segfaults.
This bug can be reproduced in Cinnamon 3.6.7, as mentioned in:
<https://github.com/linuxmint/Cinnamon/issues/7491>
This commit fixes that by always allocating a new
FreedesktopNotification before invoking dbus_call(), ensuring that the
callback always have a valid user data.
Signed-off-by: Arnaud Rebillout <elboulangero@gmail.com>
Previously, calling:
g_dbus_is_supported_address ("some-imaginary-transport:", NULL)
correctly returned FALSE; but calling:
g_dbus_is_supported_address ("some-imaginary-transport:", &error)
crashed with:
GLib-GIO:ERROR:../gio/gdbusaddress.c:434:g_dbus_is_supported_address:
assertion failed: (ret || (!ret && (error == NULL || *error != NULL)))
This was because, if the address component did not start with a known
transport, no error was set. Fix this, reusing an error string used by
the corresponding else branch in g_dbus_address_connect(), and adjust
the test to pass both NULL and non-NULL GError **s to this function in
every test case. This case:
g_assert (!g_dbus_is_supported_address ("some-imaginary-transport:foo=bar;unix:path=/this/is/valid", NULL));
would have caught this bug with a non-NULL GError **.
This test will only work on machines which have IPv6 enabled and have a
local IPv6 interface with ID 1. On machines which don’t (such as AWS
servers, which we run CI tests on), the GResolver tests will fail with
G_RESOLVER_ERROR_INVALID. We can’t differentiate this kind of failure
(where we’d want to skip the test) from an actual failure (where we’d
want to fail the test), so the only other option is to drop this
particular test vector. I don’t think it’s a significant loss.
This is the last fix needed to get our CI tests working reliably on
jenkins.gnome.org.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=795234
There are various reasons why setting up a server might fail; it
reliably fails on AWS with IPv6 addresses (are we binding to the right
address?). Since we’re trying to test GSocket as a client, skip tests
where that happens.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=795234
This fix undefined symbol link error when building for non-glibc
platform. Applications must link on libintl, it is not a public
dependency of libglib.
On glibc platforms libintl is a not found dependency and is just ignored
by meson, so it doesn't hurt to always have it.
https://bugzilla.gnome.org/show_bug.cgi?id=795406
Add a test for monitoring an existing local file, with the
WATCH_HARD_LINKS flag specified. This would previously cause a crash;
now it doesn’t.
This test contains a FIXME where I suspect we should be getting some
additional file change notifications from changes made through the hard
link; this requires further follow up and probably further fixes to our
inotify backend.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=755721
This gets the G_FILE_MONITOR_WATCH_HARD_LINKS flag to the state where it
doesn’t cause crashes, and essentially acts as a no-op. It will not yet
actually monitor for changes made via hard links.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=755721
The call to _start() fills in the dirname, basename, and filename
arguments according to the following rules:
dir watches: dirname filled
file watches: dirname and basename filled
hardlink: filename filled
This doesn't map to how the current inotify backend works very nicely,
so we need to adjust things a bit when creating our "sub" objects.
https://bugzilla.gnome.org/show_bug.cgi?id=755721
Commit 170466db accidentally partially reverted commit d1a03bc7.
Reinstate the missing check for OS X 10.9.
The Meson build does not have this problem.
https://bugzilla.gnome.org/show_bug.cgi?id=794380
If glib-networking is installed and built with libproxy support, this
test will use it. If a proxy is set in the environment, we might get
correctly told to go through it for certain accesses. However, this isn't
going to work, because the testsuite monkeys with the network monitor to
tell it that all addresses - including the proxy - aren't reachable.
We're trying to check if adding networks to a GNetworkMonitor works in
general. Proxies just get in the way here, so let's use the built in
dummy proxy resolver which just tells us that all URLs are directly
accessible.
https://bugzilla.gnome.org/show_bug.cgi?id=794801
Some very odd systems have the functions to initialise and destroy a
struct __res_state, but apparently not to do a DNS query using it. Fix
the compilation on those systems.
https://bugzilla.gnome.org/show_bug.cgi?id=794606
Tighten up the validation of application IDs so they are always exactly
D-Bus well-known names. This is a slight change to the accepted format,
but since anyone using the API with an application ID which was
previously valid, but which was not a valid D-Bus well-known name, would
have received an error from D-Bus when their application tried to
register on the bus, I think this break is acceptable.
It will affect any applications which have application IDs which are not
valid D-Bus well-known names, and which use the G_APPLICATION_NON_UNIQUE
flag. From a quick search in Debian Codesearch, no C applications use
that flag.
Update the documentation to use the rules from the D-Bus specification,
including the latest advice discouraging use of hyphens:
https://dbus.freedesktop.org/doc/dbus-specification.html#message-protocol-names-bus
Update the tests:
• Add the examples from the documentation to validate them.
• Especially the venerable 7-zip.org example.
• Move a couple of tests from expected-failure to expected-success:
they are valid D-Bus well-known names even if they’re a bit weird.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=793400
This will make the assertion failure messages a little more useful, and
prevent the assertions being compiled out with G_DISABLE_ASSERT.
Introduces no functional changes.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=793400
If the GNetworkMonitorNetlink is finalised part-way through a dump
(after request_dump() is called, but before finish_dump() is called),
dump_networks was leaked. Fix that.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=793880
This should introduce no functional changes. Factor out some common
code, flip some arguments around to use the more conventional (data,
length) order, and move some memory management calls out of
if-blocks.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=793880
By using g_timeout_source_new_seconds(), we can let timer wakeups be
coalesced by the scheduler, and reduce power consumption a bit. This
shouldn’t really affect the accuracy of the network monitoring.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=793880
Previously, the GSource would be attached to whatever GMainContext was
the thread default at the time; but that might no longer be the same as
the default at the time of constructing the GNetworkMonitor.
Save the default from construction time, so that source callbacks are
always invoked in the same GMainContext.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=793880
In doing so, ensure that g_option_context_set_ignore_unknown_options()
is always called if completion is being done.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=793597
In this situation:
$ gdbus emit --session --object-path /org/foo/bar --sig<tab><tab><tab>
We will currently insert --signal three times.
We should only do that once.
https://bugzilla.gnome.org/show_bug.cgi?id=793597
Commit faf94409083f40ed096565b4f948852323bad697 made the bash completion more
robust, but in doing so it made the optional --dest argument to `gdbus emit'
mandatory by mistake.
Remove the error case when --dest is not specified. To keep the completion
working, we shuffle the cases around. --dest should be offered up for
completion after --session/--system/--address have been supplied, so we can
complete its argument. Additionally, if --dest isn't specified then we can't
complete --object-path or --signal, so guard these completions accordingly.
https://bugzilla.gnome.org/show_bug.cgi?id=793597
When completing, we parse the options that the user has typed so far. Up
until now we've been doing this without ignoring unknown options. This
leads to broken completions when the user has typed an incomplete
parameter.
For example, when doing the following:
$ gdbus emit --session --obj<tab>
We expect --object-path to be completed, but it is currently not. What
happens is that we fail to parse the options, therefore don't act on
--session and so don't connect to the session bus, then we early-exit
because we need to know which bus to operate on for later completions.
Instead we can ignore the half-completed --obj, parse --session, get
connected to the bus and then move on to the later completion code.
https://bugzilla.gnome.org/show_bug.cgi?id=793597
