There's a race condition somewhere in GTestDBus that can result in
the next test being started at a time when g_bus_get() would still
return the connection that is in the process of closing. This can
be reproduced reasonably reliably by running the gapplication test
10K times in a loop.
Instead of relying on waiting for the weak reference to be released,
we can force the issue by clearing it.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=768996
Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=894677
This adds a null notification backend implementation for win32, purely
to avoid crashes due to a missing backend when applications use
GNotification. This backend does nothing except print a warning when a
notification is supposed to be emitted.
In future, it can be expanded to use win32 API to present toaster
notifications appropriately.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=776583
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
Explain why we say "See new_stateful()" (although it's pretty obvious).
Drop a redundant copy of the argument description in the body text.
Add a # to the GVariant type name so that we can have a nice link.
https://bugzilla.gnome.org/show_bug.cgi?id=795070
If something is nullable, it's always helpful to identify what NULL
means. Also, this is not the parameter for the .activate() vfunc, as we
take that over: rather, it is the parameter for the ::activate signal.
https://bugzilla.gnome.org/show_bug.cgi?id=795070
The `mount_monitor` variable is only set if the boolean
`with_mount_monitor` variable is set to TRUE, but the compiler does not
know that, so it'll warn when calling `g_clear_object()` even if the
clearing operation is gated with the same boolean.
Initializing with NULL does not cost us anything, and eliminates a
conditional branch.
https://bugzilla.gnome.org/show_bug.cgi?id=794732
The g_auto macros are available only with GCC-compatible compilers on
Unix, but having __attribute__((cleanup)) is not part of our toolchain
requirements, so we shouldn't use it — even if we are building on
Unix-compatible systems.
https://bugzilla.gnome.org/show_bug.cgi?id=794732
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
GSocketListener can keep internal references to itself for pending
accept() calls, which mean that it can stay alive (and keep listening
on ports) even after a user drops their last reference to it. They need
to call g_socket_listener_close() explicitly to avoid that.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=794207
There's no need to unconditionally print an error message if xmllint or
json-glib-format are not found when running glib-compile-resources is
called; we only need to warn if they are not available when we need
them. To avoid spamming the build logs, we can also warn once.
https://bugzilla.gnome.org/show_bug.cgi?id=794285
The glib-compile-resources tool has hand-rolled "open a temporary file"
code paths. Since error handling is hard, let's rely on GLib API that is
meant to do that consistently for us.
Get rid of some tabs mixed with spaces while we're at it.
https://bugzilla.gnome.org/show_bug.cgi?id=794284
Similarly to how glib-compile-resources can call xmllint to eliminate
whitespace in XML files to reduce their size inside a GResource, we can
use json-glib-format to achieve the same result.
The mechanism for using json-glib-format is the same, with a separate
environment variable if we want to direct glib-compile-resources to a
version of json-glib-format that is not the one in the PATH.
https://bugzilla.gnome.org/show_bug.cgi?id=794284
Normally, the list of mounts is filtered to exclude mounts in
/run/media/$username where $username is not the current user. However,
root can access all the mounts under /run/media/, regardless of the
username — so there’s no point in filtering out those mounts.
In some cases, filtering them out is harmful. In the case of a system
service which uses GVolumeMonitor, for example, filtering them out means
the service cannot see automounted USB sticks belonging to user
sessions.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=793994
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
- Stop using a custom thread for listening to kqueue(2) events. Instead
call kevent(2) in non blocking mode in a monitor callback. Under the
hood poll(2) is used to figure out if new events are available.
- Do not use a socketpair with a custom protocol requiring 2 supplementary
context switches per event to commicate between multiple threads. Calling
kevent(2), in non blocking mode, to add/remove events is fine from any
context.
- Add kqueue(2) events without the EV_ONESHOT flag. This removes a race
where some notifications were lost because events had to be re-added for
every new notification.
- Get rid of the global hash table and its associated lock and races. Use
the 'cookie' argument of kevent(2) to pass the associated descriptor when
registering an event.
- Fix _kh_file_appeared_cb() by properly passing a monitor instead of a
source to g_file_monitor_emit_event().
- Properly refcount sources.
- Remove a lot of abstraction making it harder to fix the remaining issues.
https://bugzilla.gnome.org/show_bug.cgi?id=739424
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 faf9440908 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