g_socket_listener_add_address() is synchronous; all of the events will
have been emitted before it returns and it doesn't queue any sources.
The test was unintentionally depending on the fact that
g_main_context_iterate(NULL, TRUE) would return anyway (at least the
first time it was called), but that's no longer true after e4ee307.
https://bugzilla.gnome.org/show_bug.cgi?id=768968
glib-compile-resources --generate is supposed to automatically detect
whether to generate source code or header from the target's file extension.
However, this only worked for C; extend this to include the canonical
C++ filename extensions. Also make the check case insensitive.
https://bugzilla.gnome.org/show_bug.cgi?id=747134
Include the filename for the file in question in many of the
error messages in glocalfile.c. This is useful information when
diagnosing such errors, so make it easily available.
http://bugzilla.gnome.org/show_bug.cgi?id=754012
The recently-added GIO tools is intended to be built on all platforms, so
adjust the code a bit to enable this:
-Use gssize instead of ssize_t, as ssize_t is not supported by all
compilers.
-Include io.h on Windows, and define STDIN_FILENO and STDOUT_FILENO if
necessary on Windows.
https://bugzilla.gnome.org/show_bug.cgi?id=768357
Ensure that @key is non-%NULL on g_settings_reset().
It turns out that using g_settings_reset() with %NULL key (although
invalid as per the API documentation and not possible via bindings)
accidentally produces the same effect as the _reset_all() API that we
are about to add.
Add the standard precondition checks to prevent that from happening.
https://bugzilla.gnome.org/show_bug.cgi?id=744678
GSettings objects were not unreffed in test_flags, test_enums and
test_ranges tests and when we skip internationalization tests, ie
test_l10n(_context).
https://bugzilla.gnome.org/show_bug.cgi?id=768560
The two known use-cases for autolaunching are:
* X-forwarding: "ssh -Y myhost myapp" resulting in a
session bus on myhost but an X server on the original host
* Legacy desktop environments on OSs without D-Bus integration:
e.g. running a single GNOME or KDE app under fvwm or something,
without a session dbus-daemon being started by either systemd,
gnome-session, or OS integration scripts analogous to Debian's
/etc/X11/Xsession.d/75dbus_dbus-launch
In either case, an X11 DISPLAY is also needed.
"dbus-launch --autolaunch" doesn't do anything useful when unable
to connect to an X11 display; this has been the case since the feature
was added in 2006, and is useful to avoid "split brain" situations in
which two processes that ought to be part of the same session end up
on separate session buses. Since dbus commit 407c111 in 2011,
libdbus hasn't even attempted to run "dbus-launch --autolaunch"
unless getenv("DISPLAY") returns non-null in the parent: this avoids
doing a relatively complicated fork-and-exec that is clearly not
going to lead to success. This commit gives GDBus the same policy.
This change was originally made to work around a race condition in
subprocess spawning (Debian bug #737380, GNOME bug #711090) but
it seems valid in its own right.
In my opinion as D-Bus maintainer, "dbus-launch --autolaunch" should
be considered to be an X11 feature, and any future D-Bus enhancements
(e.g. kdbus) or successors for X11 (e.g. Wayland, Mir) should obtain
a session bus address by other means - either a session manager
such as "systemd --user", gnome-session or Upstart, or a wrapper
for the user session like dbus-run-session(1).
Related to dbus bug <https://bugs.freedesktop.org/show_bug.cgi?id=19997>.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=723506
Bug-Debian: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=737380
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
xdg-desktop-portal support is only usable on *NIX platforms, so don't build
them on non-*NIX platforms. Also clean up gio/Makefile.am a bit to split out
the listings for the platform-specific sources from the platform-neutral
sources, and assemble them for the final list of sources required for libgio.
https://bugzilla.gnome.org/show_bug.cgi?id=768498
OS X apparently stringifies the IPv6 address "::80" as "::0.0.0.128",
which is bizarre, but that address *is* in a "reserved for future use"
range, so it's not unambiguously wrong I guess. Anyway, fix the text
to use an address everyone can agree on.
https://bugzilla.gnome.org/show_bug.cgi?id=768551
The backend for this lives in xdg-desktop-portal,
and is in turn using GNetworkMonitor.
When network is not available in the sandbox, there is
no point in reporting accurately about the network
status outside the sandbox. Just return 'no connection'
in this case.
https://bugzilla.gnome.org/show_bug.cgi?id=768498
We need to patch in the portal support at a high enough
level that GAppInfo is not involved - a sandboxed app may
not be able to see any applications, so it can only launch
the defaults.
Note that even though the API is called launch_default...,
the portal may still offer the user to choose the application
to launch.
https://bugzilla.gnome.org/show_bug.cgi?id=768498
These are private helper functions that will be used in
the following commits to get information about whether
we are running in a flatpak sandbox, etc.
We allow the use of GTK_USE_PORTAL=1 in the environment
to force the use of portals. This can be useful for
testing and debugging portal interaction.
https://bugzilla.gnome.org/show_bug.cgi?id=768498
This command collects the various commandline utilities that
are currently shipped in gvfs, and unifies them under a single,
command-style binary.
The tools just use GIO APIs, so it makes sense for them to live here.
In a vague attempt at ensuring the .stp scripts can be closely
associated with the .so files which they hard-code references to, rename
the scripts so they include the LT version — so that they are the .so
file name plus .stp.
This does not fix the fact that our .stp scripts will not work on
multiarch systems, as they are installed in an architecture-independent
directory (/usr/share/systemtap/tapset). At the moment, it is
recommended that any distribution who package the .stp files should
install them in the architecture-specific subdirectories of this (for
example, /usr/share/systemtap/tapset/x86-64).
A better long-term solution for this is under discussion upstream:
https://sourceware.org/bugzilla/show_bug.cgi?id=20264https://bugzilla.gnome.org/show_bug.cgi?id=662802
The list of supported schemes is not known at compile-time, so it is
wrong to iterate the list with G_N_ELEMENTS() and we miss all but the
first scheme. Fix by checking for the %NULL sentinel instead.
https://bugzilla.gnome.org/show_bug.cgi?id=768119
Add filesystem attribute to detect remote filesystems in order to
replace hardcoded filesystem types in GtkFileSystem. Set this attribute
also for GLocalFile appropriately.
Bump version to 2.49.3, so that early adopters of new API have a version
number to target.
If none of the closures in the hash table return a non-null value, the
loop never ends. Since the end of the hash table has been reached at
that point, g_hash_table_iter_next() starts asserting.
The possible fix is making the return value of g_hash_table_iter_next()
the condition in the loop.
https://bugzilla.gnome.org/show_bug.cgi?id=768029
Add a new API to allow clients to register a custom GFile implementation
handling a particular URI scheme.
This can be useful for tests, but also for cases where a different URI
scheme is desired to be used with another custom GFile backend.
As an additional cleanup, we can use this to register the "resource" URI
scheme too.
Based on a patch by Jasper St. Pierre <jstpierre@mecheye.net>.
https://bugzilla.gnome.org/show_bug.cgi?id=767887
5cea1c861d introduced accessors for 64bit
ints to gsettings, at which point the testcases were expanded.
Unfortunately, the expanded tests contained a bug: integer constants
passed to g_object_set() for a 64-bit property need an up-cast. Add
that now.
Problem found by Iain Lane.
If a backup file is created, opened successfully, then fstat() on it
fails (perhaps due to another process deleting it in the mean time?),
the FD will be leaked.
Coverity issue: #1159485https://bugzilla.gnome.org/show_bug.cgi?id=730187
Previously this would cause an assertion failure when checking the paths
of exported objects, as it would try to check that their paths started
with ‘//’ due to mishandling the root object case.
Includes a unit test.
https://bugzilla.gnome.org/show_bug.cgi?id=761810
proxy->priv->name_owner gets overwritten in async_init_data_set_name_owner() on the
assumption that it will always be NULL when we get there. However,
on_name_owner_changed() can run first, and it does set name_owner.
==20126== 42 bytes in 6 blocks are definitely lost in loss record 15,174 of 48,256
==20126== at 0x4C280F3: malloc (vg_replace_malloc.c:299)
==20126== by 0x7541D00: g_malloc (gmem.c:104)
==20126== by 0x7558FEE: g_strdup (gstrfuncs.c:364)
==20126== by 0x6DF8E4F: on_name_owner_changed (gdbusproxy.c:1399)
==20126== by 0x6DE94C4: emit_signal_instance_in_idle_cb (gdbusconnection.c:3743)
==20126== by 0x753C315: g_main_dispatch (gmain.c:3066)
==20126== by 0x753C315: g_main_context_dispatch (gmain.c:3642)
==20126== by 0x753C667: g_main_context_iterate.isra.24 (gmain.c:3713)
==20126== by 0x753CA69: g_main_loop_run (gmain.c:3907)
==20126== by 0x5E38000: meta_run (main.c:556)
==20126== by 0x401EC0: main (main.c:441)
https://bugzilla.gnome.org/show_bug.cgi?id=755439
This fixes a build failure in Continuous that resulted in the error:
../../../gio/tests/test.gresource.xml: Failed to locate
'test-generated.txt' in any source directory.
Makefile:4676: recipe for target 'test.gresource' failed
make[6]: *** [test.gresource] Error 1
Nautilus wants to show entries in the sidebar only for removable devices.
It uses currently sort of conditions to determine which devices should be
shown. Those condition fails in some cases unfortunatelly. Lets provide
g_drive_is_removable() which uses udisks Removable property to determine
which devices should be shown. It should return true for all drives with
removable media, or flash media, or drives on usb and firewire buses.
https://bugzilla.gnome.org/show_bug.cgi?id=765900
This prevents testsuite from trying to build any TESTS in that
subdirectory, which will fail, because there are no TESTS defined
in that Makefile.am.
This happens when user runs make check TESTS=...
https://bugzilla.gnome.org/show_bug.cgi?id=766407
This adds a new --c-generate-autocleanup option to gdbus-codegen
which can be used to instruct gdbus-codegen about what autocleanup
definitions to emit.
Doing this unconditionally was found to interfere with existing
code out in the wild.
The new option takes an argument that can be
none, objects or all; to indicate whether to generate no
autocleanup functions, only do it for object types, or do it
for interface types as well. The default is 'objects', which
matches the unconditional behavior of gdbus-codegen on the 2.48
branch.
https://bugzilla.gnome.org/show_bug.cgi?id=763379
The use of past tense in g_task_had_error makes one assume that it
won't forget about any errors that might have occurred. Except, in
reality, it would.
Let's use a boolean flag to remember the error once it's been
propagated, as opposed to keeping the error around. This ensures that
the g_task_propagate_* methods continue to give invalid results when
called more than once, as mentioned in the documentation.
https://bugzilla.gnome.org/show_bug.cgi?id=764163
Some GNOME projects unconditionally work around the generated code's
lack of g_autoptr support by defining the autoptr cleanup function
themselves, which is not forward-compatible; as a result, commit
cbbcaa4 broke them. Do not define the cleanup function unless the
including app "opts in" to newer APIs via GLIB_VERSION_MAX_ALLOWED.
Projects requiring compatibility with GLib < 2.49 can get a
forward-compatible g_autoptr for a generated GInterface type found in
a library, for example ExampleAnimal in the GIO tests, by declaring
and using a typedef with a distinct name outside the library's
namespace:
typedef AutoExampleAnimal ExampleAnimal;
G_DEFINE_AUTOPTR_CLEANUP_FUNC (AutoExampleAnimal, g_object_unref)
...
g_autoptr (AutoExampleAnimal) animal = NULL;
/* returns ExampleAnimal * */
animal = example_animal_proxy_new_sync (...);
/* takes ExampleAnimal * first argument */
example_animal_call_poke_sync (animal, ...);
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=763379
Reviewed-by: Colin Walters <walters@verbum.org>
Reviewed-by: Emmanuele Bassi <ebassi@gnome.org>
The rest of the generated classes gained g_autoptr support in fd6ca66,
but this one is still missing. Because whatever_proxy_new_finish() and
whatever_proxy_new_sync() are declared as returning a Whatever *
instead of a WhateverProxy *, and the generated method-call stubs
act on a Whatever *, it's reasonably common to want to declare a
g_autoptr (Whatever).
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Bug: https://bugzilla.gnome.org/review?bug=763379
Reviewed-by: Colin Walters <walters@verbum.org>
gdbus-tool prints a hint about the expected arguments to a function call
in case of errors. Unfortunately, it prints this message on all errors.
I've seen this confuse users several times -- they go on tweaking the
arguments trying to get the correct type, even though they had it
correct in the first place.
Let's limit the hint to the case where it was actually invalid arguments
that triggered the problem. Also, adjust the code that prints the
message so that it will also report on the case that no arguments were
expected.
We could possibly get closer to what we want by comparing the list of
expected arguments with the parameter list, as it was parsed from the
user, but that would involve composing the expected type. Let's keep
this simple for now.
https://bugzilla.gnome.org/show_bug.cgi?id=765710
When debugging a program or testing a change to an installed version, it
is often useful to be able to replace resources in the program or a
library, without recompiling.
To support this, for debugging and hacking purposes, it's now possible
to define a G_RESOURCE_OVERLAYS environment variable as a
colon-separated list of substitutions to perform when looking up
GResources.
A substitution has the form
"/org/gtk/libgtk=/home/desrt/gtk-overlay"
The part before the '=' is the resource subpath for which the overlay
applies. The part after is a filesystem path which contains files and
subdirectories as you would like to be loaded as resources with the
equivalent names.
In the example above, if an application tried to load a resource with
the resource path '/org/gtk/libgtk/ui/gtkdialog.ui' then GResource would
check the filesystem path '/home/desrt/gtk-overlay/ui/gtkdialog.ui'. If
a file was found there, it would be used instead.
Substitutions must start with a slash, and must not have a trailing
slash before the '='. It is possible to overlay the location of a
single resource with an individual file.
https://bugzilla.gnome.org/show_bug.cgi?id=765668
Replace the hand-written equivalent of this with the call to the
GHashTable built-in version to save a few lines of code.
The GResource code was written a couple of years before this function
existed.
Similarly, replace a set-mode usage of g_hash_table_insert() with a call
to g_hash_table_add().
https://bugzilla.gnome.org/show_bug.cgi?id=765668
GContextSpecificGroup has been somewhat broken for a rather long time:
when we remove the last reference on an object held in the group, we try
to clean up the source, but fail to actually remove it from the
mainloop.
We will soon stop emitting signals on the source (due to it having been
removed from the hash table) but any "in flight" signals will still be
delivered on the source, which continues to exist. This is a problem if
the event is being delivered just as the object is being destroyed.
This also means that we leave the source attached to the mainloop
forever (and next time will create a new one)...
This is demonstrated with the GtkAppChooser dialog which writes an
update to the mimeapps.list file just as it is closing, triggering the
app info monitor to fire just as it is being destroyed.
Karl Tomlinson correctly analysed the problem and proposed this fix.
https://bugzilla.gnome.org/show_bug.cgi?id=762994
GApplication has accepted any valid bus name as an application ID since
before the time of D-Bus activation. This includes bus names with '-'.
Several applications have even attempted support bus activation with
these names, going as far as installing D-Bus service files, without
realising that they are silently falling back to fork()/exec() on
account of the name containing a dash.
The reason for the problem is that D-Bus object paths cannot contain
dashes. We solved this problem privately in an unspecified way inside
of GApplication but substituting '_' in this case, but never made this
part of the Desktop Entry Specification.
The fact that these apps with '-' in the desktop file names aren't
actually using D-Bus activation is beside the point: their intent here
was clear. Let's avoid forcing them to rename their desktop files again
by simply accepting '-' in desktop file names and munging the path in
the way that GApplication did so historically.
The new path escaping code here has been copied more or less verbatim
from GApplication's own code for the same purpose, with only the removal
of one irrelevant part.
An update to the desktop entry specification will follow.
https://bugzilla.gnome.org/show_bug.cgi?id=764754
This was confusing some static analysis. Through canonicalize_filename()
at construction time, we guaranteed that ->filename is canonical and
absolute, so g_path_skip_root() should never fail.
https://bugzilla.gnome.org/show_bug.cgi?id=731988
This ensures that the generated file is always the same (not dependent
on the build machine's environment), making the build reproducible.
Thanks to Jérémy Bobbio <lunar@debian.org> for the Debian bug report and
patch.
https://bugzilla.gnome.org/show_bug.cgi?id=763617
Even though GetStartupInfo() in g_win32_run_session_bus() would
tell us that STARTF_FORCEONFEEDBACK flag is not set, it still
affects the rundll32 process for some reason.
This means that Windows WM changes mouse cursor to IDC_APPSTARTING for
a few seconds when rundll32 runs g_win32_run_session_bus(). Since
g_win32_run_session_bus() never satisfies the conditions set by
STARTF_FORCEONFEEDBACK, the busy cursor only goes away after a
timeout.
Fix this by explicitly running GetMessage(). To ensure that GetMessage()
doesn't block, post a quit message immediately before calling it.
https://bugzilla.gnome.org/show_bug.cgi?id=760694
Some applications support running in a mode where they present
themselves as a different application to the user (for example web
browsers or terminals).
To facilitate this, add an option --gapplication-app-id which allows
users to override an application's id from desktop files or similar.
Applications need to opt-in to this by setting the
G_APPLICATION_CAN_OVERRIDE_APP_ID flag.
https://bugzilla.gnome.org/show_bug.cgi?id=743933
currently schema_list will iterate over the default SchemaSource
list, and not the one associated with the passed in Schema. This
means schema_list can give incorrect results for a Schema fetched
from a non-default SchemaSource, like via new_from_directory.
https://bugzilla.gnome.org/show_bug.cgi?id=757506
Perform conversion before writing a value out of the cache into the registry,
and convert back when reading a value into the cache out of the registry.
The registry holds UTF-8 strings.
This is a flag used to understand if a key exists on the registry
and if it is readable. It makes more sense to rename it as readable
since anyway a key that does not exists anymore is a key that is
not readable.
The documentation of g_file_info_copy_into() was misleading. The
attributes are not just copied, @dest_info is also cleared at the
beginning. So any previously set attributes in @dest_info are lost.
There was a bug in gedit about this function, where some metadata were
not saved. So it might make sense to change the implementation to not
clear @dest_info, and copy one by one the attributes from @src_info to
@dest_info.
https://bugzilla.gnome.org/show_bug.cgi?id=747927
I'm tired of seeing 'No such file or directory' in the logs without
a hint as to what is actually wrong. Including the filename here
may help me tracking down a bug in the continuous infrastructure.
Visual Studio, at least the older versions, cannot use L on macros which
are defined as a constant string, plus the L must be applied to all string
literals here. This does not look nice, but this is life...
Rather than calculating it at configure time. This means it can expand
$libdir properly, and use the Make $(realpath) function rather than
invoking the non-portable `readlink -f`.
This fixes problems where `readlink` would be called on an invalid path
(due to a variable not being expanded) and would evaluate to "", which
would then cause things to be installed in the wrong place.
https://bugzilla.gnome.org/show_bug.cgi?id=744772
Add a new GDtlsConnection interface, plus derived GDtlsClientConnection
and GDtlsServerConnection interfaces, for implementing Datagram TLS
support in glib-networking.
A GDtlsConnection is a GDatagramBased, so may be used as a normal
datagram socket, wrapping all datagrams from a base GDatagramBased in
DTLS segments.
Test cases are included in the implementation in glib-networking.
https://bugzilla.gnome.org/show_bug.cgi?id=752240
We changed the behaviour of this API to adapt to a change in the D-Bus
specification. Document the new behaviour, along with the time of the
change.
https://bugzilla.gnome.org/show_bug.cgi?id=755421
gdbus sets NO_REPLY_EXPECTED when no callback is given to
g_dbus_connection_call(). It makes sense that it also handles the server
side correctly by discarding replies to clients that don't want one.
https://bugzilla.gnome.org/show_bug.cgi?id=755421
This causes several problems:
- Compilation in FreeBSD with --enable-gtk-doc broke
- Modules that still use the AM_GLIB_GNU_GETTEXT macro
doesnt compile anymore because /usr/share/glib-2.0/gettext
is not filled with the correct files, as this was done in
the glib custom po/Makefile.in.in
See https://bugzilla.gnome.org/show_bug.cgi?id=622991
This reverts commit e5c752371c.
I think it is a recursion from the GUnixMountMonitor constructor, to a
GLocalFileMonitor on /etc/fstab, and into GUnixMountMonitor again, now
with a mutex already held, so it deadlocks.
https://bugzilla.gnome.org/page.cgi?id=traceparser/trace.html&trace_id=235354
That mutex in glocalfile.c:g_local_file_find_enclosing_mount() doesn't
seem necessary any more IMHO. Inside it, only 'mount' is modified, but
that's just a stack variable local to this function. When
klass->get_mount_for_mount_path is called, it's given one const
parameter and the other is unused, so they're unchanged. 'klass'
doesn't seem it could be modified either inside that function.
It doesn't recurse infinitely, but seems to work correctly and pass the
testsuite after this change.
The FreeBSD project already applied my patch in their ports tree, and
their users seem happy with it.
See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=712848#64
and https://bugzilla.gnome.org/show_bug.cgi?id=753378
As g_win32_get_command_line() calls CommandLineToArgvW() to acquire the
arguments passed into a GApplication program, it actually returns the
whole command line which is used to invoke the program, including the
script interpreter and its flags when a script using GNOME bindings
(e.g. PyGObject and so on) is being invoked.
The issue here is that g_application_run() would most probably have
trouble in the scripts scenario on Windows as it is likely unable to
"recognize" the script interpreter, causing such scripts to fail to run.
Largely based on the patch by Ray Donnelly <mingw.android@gmail.com>.
https://bugzilla.gnome.org/show_bug.cgi?id=734095
Otherwise, we'll acquire it on every loop iteration, which can leave us
vulnerable to racing another thread for the acquisition of the main
context.
This can break methods like g_main_context_invoke, which try to acquire
a context to figure out if it can invoke the method synchronously or
need to defer to an idle. In these cases, it isn't guaranteed that the
invocation function will be invoked in the default main context,
e.g. the one that GApplication is holding.
This also matches what GMainLoop is doing.
https://bugzilla.gnome.org/show_bug.cgi?id=752983
* On W32 use a real directory (SYSTEMROOT) instead of '/etc/'
* Disable test_symbolic_icon() as it can't be passed (symbolic icons are not
really supported)
* PowerPoint/Gettext test still fails, presumably because msvcrt qsort() moves
the entires (both have the same priority)
https://bugzilla.gnome.org/show_bug.cgi?id=735696
Allocate an empty cache object, check cache objects for being empty
before using them.
Otherwise the code will re-read cache every 5 seconds, as NULL cache
does not trigger the code that stores mtime, which makes the cache
file appear modified/unloaded permanently.
https://bugzilla.gnome.org/show_bug.cgi?id=735696
As per #578363, "if one requests e.g. strings via GOptionEntry.arg_data
then those are strduped and needs to be free'ed by the application."
Fixes following leak:
=================================================================
==29426==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 10 byte(s) in 1 object(s) allocated from:
0 0x7f3ab783d37a in malloc (/usr/lib/x86_64-linux-gnu/libasan.so.2+0x9437a)
1 0x7f3ab70f7c82 in g_malloc /home/lebedevri/src/glib/glib/gmem.c:94
2 0x7f3ab70f7f60 in g_malloc_n /home/lebedevri/src/glib/glib/gmem.c:330
3 0x7f3ab713258e in g_strndup /home/lebedevri/src/glib/glib/gstrfuncs.c:425
4 0x7f3ab709c86b in strdup_len /home/lebedevri/src/glib/glib/gconvert.c:864
5 0x7f3ab709c966 in g_locale_to_utf8 /home/lebedevri/src/glib/glib/gconvert.c:905
6 0x7f3ab7103c32 in parse_arg /home/lebedevri/src/glib/glib/goption.c:1276
7 0x7f3ab71066fb in parse_long_option /home/lebedevri/src/glib/glib/goption.c:1670
8 0x7f3ab7108047 in g_option_context_parse /home/lebedevri/src/glib/glib/goption.c:1997
9 0x408532 in main /home/lebedevri/src/glib/gio/glib-compile-resources.c:629
10 0x7f3ab6c72b44 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b44)
https://bugzilla.gnome.org/show_bug.cgi?id=757299
It's theoretically possible (and see in the wild) for D-Bus messages to
come in to the application after shutdown() has been called and while
we're draining out the lingering events in the main context.
Prevent this from happening by ensuring we unregister our objects on
D-Bus during the shutdown process.
https://bugzilla.gnome.org/show_bug.cgi?id=757372
Bug 13403 introduced support for the non-POSIX variants of these APIs
found on a system called "DG/UX". Meanwhile, the complicated checks
here are breaking cross-builds on systems that we actually care about.
Remove the complicated checks and replace them with AC_CHECK_FUNCS.
Remove the resulting dead code from a couple of .c files.
https://bugzilla.gnome.org/show_bug.cgi?id=756475
Add various (nullable) and (optional) annotations which were missing
from a variety of functions. Also port a couple of existing (allow-none)
annotations in the same files to use (nullable) and (optional) as
appropriate instead.
Secondly, add various (not nullable) annotations as needed by the new
default in gobject-introspection of marking gpointers as (nullable). See
https://bugzilla.gnome.org/show_bug.cgi?id=729660.
This includes adding some stub documentation comments for the
assertion macro error functions, which weren’t previously documented.
The new comments are purely to allow for annotations, and hence are
marked as (skip) to prevent the symbols appearing in the GIR file.
https://bugzilla.gnome.org/show_bug.cgi?id=719966
Commit 8ece2de964 transplanted a block of
code that contained an early-exit-on-error case which freed several
variables.
Because of the move, the normal-path unconditional free of one of these
variables is now above this early exit case, so if this block is hit, it
will now be a double-free.
Remove that.
https://bugzilla.gnome.org/show_bug.cgi?id=757693
It was removed, apparently accidentally, in commit 5b48dc4.
This had the side-effect that it wasn't included in tarball releases,
which means that commit ab7b4be doesn't work when building a package.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=734469
Reviewed-by: Colin Walters <walters@verbum.org>
The new "slowly add more task threads" code doesn't fully deal with
apps that queue lots and lots of tasks which then block on tasks from
their task threads. Fix this by bringing back the "task is blocking
other task" check and making sure that such tasks get bumped to the
front of the queue.
https://bugzilla.gnome.org/show_bug.cgi?id=687223
Recent changes to file monitors removed the delay before events were
reported. Among other things, this caused the trash backend of gvfs to
notice trashed files sooner than before.
On noticing trashed files, the backend tries to read the info file to
discover (among other things) the original location of the file.
Unfortunately, g_local_file_trash() does a strange dance when trashing a
file. It does a loop of open(O_EXCL) in order to file an empty filename
in the trash to write an info file to, trashes the file, and only then
writes the contents of the info file. This means that at the time the
file is moved to the trash, the info file is an empty stub.
Change the order so that we write out the actual content of the info
file first. If the actual trash files then we will unlink the info file
anyway.
https://bugzilla.gnome.org/show_bug.cgi?id=749314
Add string serialisation functions for GNetworkAddress, GSocketAddress,
GUnixSocketAddress, GInetSocketAddress, GNetworkService and
GSocketConnectable. These are intended for use in debug output, not for
serialisation in network or disc protocols.
They are implemented as a new virtual method on GSocketConnectable:
g_socket_connectable_to_string().
GInetSocketAddress and GUnixSocketAddress now implement
GSocketConnectable directly to implement to_string(). Previously they
implemented it via their abstract parent class, GSocketAddress.
https://bugzilla.gnome.org/show_bug.cgi?id=737116
GDatagramBased is an interface abstracting datagram-based communications
in the style of the Berkeley sockets API. It may be contrasted to (for
example) GIOStream, which supports only streaming I/O.
GDatagramBased allows socket-like communications to be done through any
object, not just a concrete GSocket (which wraps socket()).
This adds the GDatagramBased interface, and implements it in GSocket.
https://bugzilla.gnome.org/show_bug.cgi?id=697907
When G_OUTPUT_STREAM_CLOSE_TARGET is set,
g_output_stream_real_splice was not returning -1 in any error
cases, since the success flag was being overwritten.
https://bugzilla.gnome.org/show_bug.cgi?id=756255
The environment variable DISPLAY makes sense only for X11, it should
not be set in gio.
Beside, if the backend is not X11 but Wayland, forcing the value of
DISPLAY to the Wayland display will confuse the backend selection and
possibly crash the applications.
https://bugzilla.gnome.org/show_bug.cgi?id=754983
Commit a0cefc2217 introduced an unresolved
symbol, g_socket_send_message_with_timeout(), on win32. Windows
unfortunately isn’t clever enough to fill in the gaps and magic up the
implementation of that function from nowhere, so we had better do it
ourselves.
Factor the blocking behaviour out of g_socket_send_message() into a new
internal g_socket_send_message_with_timeout().
https://bugzilla.gnome.org/show_bug.cgi?id=756054
5d68947 factored out resuable items, but some of these are only for
*NIX builds, which will break the build on Windows. Fix this by
building these portions only when !G_OS_WIN32.
https://bugzilla.gnome.org/show_bug.cgi?id=756053
The value of g_socket_is_connected() gets stuck high if the GSocket is
shut down in two steps:
g_socket_shutdown (socket, TRUE, FALSE, NULL);
g_socket_shutdown (socket, FALSE, TRUE, NULL);
rather than one:
g_socket_shutdown (socket, TRUE, TRUE, NULL);
Fix that by tracking the connected status for the read half and the
write half of the connection separately.
https://bugzilla.gnome.org/show_bug.cgi?id=697907
set_auth_msg() was returning FALSE to indicate error, but all its
callers were expecting a negative return value to indicate error. This
was causing memory leaks for the GError, and errors to not be reported.
Coverity CID: 1325357
If the certificate constructor is called as:
g_tls_certificate_new_from_pem (data, length, NULL);
and PEM parsing fails for the private key, the function would have
continued to try and create a certificate using a NULL key_pem value,
which would have failed or crashed.
Use g_propagate_error() correctly to avoid this.
Coverity CID: 1325403
If an error in the underlying sendmmsg() syscall occurs after
successfully sending one or more messages, g_socket_send_messages()
should return the number of messages successfully sent, rather than an
error. This mirrors the documented sendmmsg() behaviour.
This is a slight behaviour change for g_socket_send_messages(), but as
it relaxes the error reporting (reporting errors in fewer situations
than before), it should not cause problems.
https://bugzilla.gnome.org/show_bug.cgi?id=751924
Add support for receiving multiple messages with a single system call,
using recvmmsg() if available. Otherwise, fall back to looping over
g_socket_receive_message().
This adds new API, g_socket_receive_messages(), and corresponding unit
tests.
https://bugzilla.gnome.org/show_bug.cgi?id=751924
In order to support per-operation timeouts on new API like
g_socket_receive_messages(), the internal GSocket API should use
timeouts rather than boolean blocking parameters.
(timeout == 0) === (blocking == FALSE)
(timeout == -1) === (blocking == TRUE)
(timeout > 0) === new behaviour
https://bugzilla.gnome.org/show_bug.cgi?id=751924
This complements the GOutputMessage struct. It will shortly be used for
adding a g_socket_receive_messages() function, but needs to be committed
first to allow some internal refactoring of GSocket.
https://bugzilla.gnome.org/show_bug.cgi?id=751924
Previously, GLib returned text/plain for empty files.
This is important because people may want to open empty (eg:
just-created) text files with the text editor.
An unintended side-effect of b6fc1df022
caused GLib to start returning application/octet-stream instead of
text/plain for these files.
This commit is essentially a revert of that commit, with a different
solution: we move the special-case up a bit in the function and
hard-code it to text/plain.
This change does not exactly maintain the old behaviour: previously, a
"fast" lookup would have returned application/octet-stream on an empty
file and now it will return text/plain. I consider this to be an
improvement (since we're returning better data) and don't expect it to
cause problems.
https://bugzilla.gnome.org/show_bug.cgi?id=755795
The API design here is a bit awkward — the in/out flags argument should
actually have been an in flags argument and an out msg_flags argument.
Clarify that a bit in the documentation.
https://bugzilla.gnome.org/show_bug.cgi?id=751924
_wstat32i64() doesn't exist in msvcrt.dll. This doesn't cause a problem
on 32-bit Windows because mingw-w64 #defines _wstat32i64 to _wstati64,
but on 64-bit Windows we get a link error.
In addition, _wstat32i64() takes a struct _stat32i64 *, but
GLocalFileStat is #defined to struct _stati64, which is not the same
type on 64-bit Windows.
Fix by using _wstati64().
https://bugzilla.gnome.org/show_bug.cgi?id=749161
Make use of the common autotools module that is used to generate the MSVC
project files from their respective templates so that the main build files
beccome cleaner, and enhance them in a way that the headers that should be
installed can be written to the property sheets during 'make dist', so that
the chances of missing headers for MSVC builds can be greatly reduced.
Also use this autotools module to fill in the projects for
glib-compile-schemas and glib-compile-resources.
https://bugzilla.gnome.org/show_bug.cgi?id=735429
We don't need to run binaries we just built in order to successfully
build GLib and friends any more.
Since commit b74e2a7, we don't need to run glib-genmarshal when building
GIO; since commit f9eb9eed, all our tests (including the ones that do
need to run binaries we just built) are only built when running "make
check", instead of unconditionally at every build.
This means that we don't need to check for existing, native binaries
when cross-compiling, and fail the configuration step if they are not
found — which also means that you don't need to natively build GLib for
your toolchain, in order to cross-compile GLib.
We can also use the cross-compilation conditional, and skip those tests
that require a binary we just built in order to build.
https://bugzilla.gnome.org/show_bug.cgi?id=753745
GListStore already has a g_list_store_insert_sorted function,
which can be used to keep the list sorted according to a fixed
sort function. But if the sort function changes (as e.g. with
sort columns in a list UI), the entire list needs to be
resorted. In that case, you want g_list_store_sort().
https://bugzilla.gnome.org/show_bug.cgi?id=754152
Enhance GTestTlsBackend to allow setting the issuer property of
GTlsCertificates, and add a test to ensure certificate chain
construction with g_tls_certificate_new_from_pem() works as expected.
https://bugzilla.gnome.org/show_bug.cgi?id=754264
If a private key (or anything, in fact) follows the final certificate in
the file, certificate parsing will be aborted and only the first
certificate in the chain will be returned, with the private key not set.
Be tolerant of this, rather than expecting the final character in the
file to be the newline following the last certificate.
https://bugzilla.gnome.org/show_bug.cgi?id=754264
If @error is NULL then we don't even need to evaluate the remaining
arguments. And if errno is EWOULDBLOCK, then no one should see the
error message anyway, so don't bother g_strdup_printf'ing up a pretty
one.
https://bugzilla.gnome.org/show_bug.cgi?id=752769
If you called g_dbus_connection_remove_filter() on a filter while it
was running (or about to be run) in another thread, its GDestroyNotify
would be run immediately, potentially causing the filter thread to
crash.
Fix this by refcounting the filters, and using the existing mechanism
for running a GDestroyNotify in another thread in the case where the
the gdbus thread is the one that frees it.
Also, add a bit of documentation explaining this (and add a related
clarification to g_dbus_connection_signal_subscribe()).
https://bugzilla.gnome.org/show_bug.cgi?id=704568
This will prevent attempting to read from some files that appear normal but are
really device-like, such as those in /proc and /sys.
If we can't stat() the file then don't bother attempting to sniff, either.
https://bugzilla.gnome.org/show_bug.cgi?id=708525
FreeBSD and NetBSD have field st_birthtim and st_birthtime in struct stat,
respectively, which can be used to get file creation time on supported file
systems such as UFS2 and tmpfs.
https://bugzilla.gnome.org/show_bug.cgi?id=749492
gvfs commit b358ca "Make sure metadata is always returned by
query_writable_namespaces()" changed the
query_writable_namespaces vfunc to never return NULL, but the error
checking in g_daemon_file_query_writable_namespaces still assumes vfunc
failure implies NULL return value and GError set. This causes a memory
leak as on failure the GError will be set but the vfunc implementation
will have created its own default list so NULL will not be returned, and
the GError will never be cleared.
This commit directly checks if the GError is set to detect failures,
my_error is directly dereferenced in the error block anyway.
This also removes an unneeded call to g_file_attribute_info_new(); as
the vfunc always returns us a non-NULL GFileAttributeInfoList.
https://bugzilla.gnome.org/show_bug.cgi?id=747364
These tests clear up a misunderstanding of mine: Monitoring
nonexisting files and directories *does* work with the inotify
implementation, it just has a very long timeout for scanning
for missing locations, so the test needs to take that into
account.
This is meant for opaque, non-POSIX-like backends to indicate that the
URI is not persistent. Applications should look at
G_FILE_ATTRIBUTE_STANDARD_SYMLINK_TARGET for the persistent URI.
Examples of such backends could be a portal for letting sandboxed
applications access the file-system, or a database-backed storage like
Google Drive.
In these cases, the user visible file and folder names are different
from the real identifiers, used by the backend. So, a request to
create google-drive://user@gmail.com/foo/New\ File, would actually
lead to google-drive://user@gmail.com/foo/bar on the server even though
the user visible name is still "New File". Since the server-defined URI
is persistent and sanity-checked by the backend, it is recommended that
applications switch to it as soon as possible. Backends will try to
keep a mapping from "fake" to "real" URIs, but those are only on a
best effort basis. They might not be persistent or have the same
guarantees as the "real" URIs.
https://bugzilla.gnome.org/show_bug.cgi?id=741602
g_dbus_method_invocation_return_value(), etc, don't have GError
parameters (which makes sense since they won't usually return errors,
and there's not much you could do if they did), so in the rare case
when something does go wrong, they print a warning.
However, there is at least one situation where the warning is a bad
idea: if you are using private bus connections, and a client connects,
makes a request, and then disconnects before getting the response.
Given that there's nothing the caller can do to prevent this case from
getting hit (since the client might not disconnect until after the
call to g_dbus_method_invocation_return_value() starts) and given that
the server can never actually know for sure that the client has
received the response (it might disconnect after reading the response,
but before processing it), just kill the warning in this case.
https://bugzilla.gnome.org/show_bug.cgi?id=753839
Add a new test which checks that atomically replacing a file that
is being monitored by GFileMonitor produced the expected events.
The test can easily be expanded to cover other file monitoring
scenarios.
After the big file monitoring rewrite, we only put the IN_MOVED_FROM event
in the queue for such pairs. It matches INOTIFY_DIR_MASK and thus we call
ip_dispatch_event on it, but that function was filtering it out because
the filename in the 'from' event is the one of the temp file, not the
one we are monitoring. That name is in the 'to' event, so compare it as
well, and let the event passin that case.
There is another instance of this check in glocalfilemonitor.c, which is
corrected here as well.
https://bugzilla.gnome.org/show_bug.cgi?id=751358
This is a binding-friendly version of g_dbus_connection_register_object.
Based on a patch by Martin Pitt and the code of g_bus_watch_name_with_closures.
https://bugzilla.gnome.org/show_bug.cgi?id=656325
exit-on-close for a DBus connection is a completely normal thing. On
a regular GNOME login, gdm retains the X server, but terminates the
session login bus and associated helpers like gnome-settings-dameon,
the a11y tools, etc.
I've seen several downstream reports of confusion as to what these
apparent error messages mean in the system log. It doesn't help
that they're so obtuse.
We're also printing them to stderr, when this is not an error.
The reason this was introduced is presumably some people were confused
as to why their process exited when the system bus did. But the
solution for that I believe is documentation, not printing stuff to
everyone's system log in normal operation.
https://bugzilla.gnome.org/show_bug.cgi?id=742386
The previous commit introduced a possible memory leak in cases
where we get a G_IO_ERROR_CLOSED error. Make sure to always
free an error, if we got one.
https://bugzilla.gnome.org/show_bug.cgi?id=753278
There are real world cases where emitting signals can fail, such
as if the DBus connection closes. Asserting and aborting the process
in these cases is just plain lazy.
Ignore the errors when the connection is closed, and turn the
others into warnings.
https://bugzilla.gnome.org/show_bug.cgi?id=753278
Add a property to GNetworkMonitor indicating if the network
is metered, e.g. subject to limitations set by service providers.
The default value is FALSE
https://bugzilla.gnome.org/show_bug.cgi?id=750282
A signal accumulator can return TRUE to continue signal emission, and
FALSE to stop signal emission. handle-local-options callbacks can return
« return a non-negative option if you have handled your options and
want to exit the process ».
Currently, g_application_handle_local_options_accumulator (the
accumulator for the handle-local-options signal) returns TRUE on
non-negative return value (ie continue signal emission), and returns
FALSE on negative return values (ie when the default option processing
should continue).
This return value seems backward as on >= 0 values, subsequent
handle-local-options callbacks could overwrite the 'exit request' from
the handler, while on < 0 values, the handle-local-options processing
could end up early if several callbacks are listening for this signal.
In particular, the default handler for this signal
(g_application_real_handle_local_options) always returns -1 and will
overwrite >= 0 return values from other handlers.
This commit inverts the check so that signal emission stops early when
one of the handle-local-options callbacks indicates it wants processing
to stop and the process to exit.
https://bugzilla.gnome.org/show_bug.cgi?id=751598
We already have start, stop and is_active methods, but turning it
into a real property is useful for a few reasons:
- it allows us to bind the property to an UI or a setting
- it allows us to get notified when the state changes
- it allows us to instantiate objects directly in the stopped state
https://bugzilla.gnome.org/show_bug.cgi?id=752089
Also add g_app_info_get_fallback_for_type() and
g_app_info_get_recommended_for_type() as proxies for
g_app_info_get_all_for_type(), until gcontenttype support is improved.
This code was out of date with current coding practices.
Nowadays it's common to receive file descriptors over environment
variables from other processes like systemd. The unit files that
control these file descriptors are configurable by sysadmins.
It is not (necessarily) a programmer error when g_socket_details_from_fd()
is called with a file descriptor that is not a socket. It can also
be a system and/or configuration error.
https://bugzilla.gnome.org/show_bug.cgi?id=746339
In 4e7d22e268, deleting the file was moved
after the assertion which checks for the changed event that results from
it being deleted. This is the wrong way around and makes the assertion
fail.
Move the deletion back up before we check the condition. delete_app is
no longer an idle callback so it can be made void. The change
notification might come in when the loop isn't running now, so don't try
to quit if it isn't running. In this case we'll wait for the three
second timeout and the test will still pass.
https://bugzilla.gnome.org/show_bug.cgi?id=751737
When a task is cancelled, we want to move it to the front
of the queue - our sort function does that for us, but there
is no need to resort the entire queue here, we can just
move the one item and be done with it. This uses just-introduced
threadpool api for this purpose.
https://bugzilla.gnome.org/show_bug.cgi?id=751160
Make sure to initialize the notification backend in
g_application_withdraw_notification() the same way as is done in
g_application_send_notification().
This makes it possible for an app to withdraw notifications it has sent
in a previous execution of the application.
https://bugzilla.gnome.org/show_bug.cgi?id=750625
We need to be more careful when we try to assign values to gpointers, so
that means we have to assign the value to the properly-dereference
gpointer, so that the assigned value will be retained after the function
returns. This code will be dropped soon, but it is done for XP
compatibility's sake for 2.44.
Should fix the issue reported in bug 730352 comment #24.
For performance reasons we should always try to send or
receive our messages first and only wait for more space
or data to become available if we get an EAGAIN (and
are in blocking mode).
https://bugzilla.gnome.org/show_bug.cgi?id=751122
This can be handy when you want to change the sense of a toggle
in the UI without rewriting the underlying logic. Currently, this
is just exposed as a construct-only property. We may add a
convenience wrapper or a special !property syntax for this later.
https://bugzilla.gnome.org/show_bug.cgi?id=728489
This is the right thing to do for the "a session is a user-session"
model implemented in dbus 1.9.14, which is described in
<http://lists.freedesktop.org/archives/dbus/2015-January/016522.html>.
It also resembles sd-bus' behaviour, although sd-bus will only try
kdbus and XDG_RUNTIME_DIR/bus, and never runs dbus-launch.
On systems following the more traditional "a session is a login-session"
model, X_R_D/bus won't exist, so it is harmless to check for it before
falling back to X11 autolaunching. Again, this matches the behaviour
of current libdbus and sd-bus versions.
Now that we do this, g_test_dbus_unset() needs to clear XDG_RUNTIME_DIR
as well as everything else.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=747941
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Philip Withnall <philip.withnall@collabora.co.uk>
This only alters what happens if we specifically connect to
"autolaunch:", for instance via "DBUS_SESSION_BUS_ADDRESS=autolaunch:".
We will still potentially try other platform-specific things if
DBUS_SESSION_BUS_ADDRESS is unset. There are currently no other
platform-specific things, so there is no practical difference yet,
but I'm about to add a more-preferred fallback path before autolaunch.
This matches libdbus' behaviour and the D-Bus Specification, in which
the autolaunch: transport specifically means X11 autolaunch
(as implemented by "dbus-launch --autolaunch") on Unix, or a
shared-memory-based protocol on Windows. Other platform-specific
transports or default/fallback modes, including launchd on Mac OS X
and XDG_RUNTIME_DIR/bus on Unix, are not part of "autolaunch:".
It's rather unfortunate that the same name means two different
platform-specific mechanisms, specific to different platforms -
if they were added today I'd call them x11: and windows-shm: or
something - but it's been like this since 2007 so it's too late now.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=747941
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Philip Withnall <philip.withnall@collabora.co.uk>
Currently, applications using g_application_add_main_option_entries()
won't get translated entries in --help output. We need to call
g_option_group_set_translation_domain() with a NULL domain to ensure that the
default application gettext domain (ie the one passed to the
textdomain() call) will be used for the main entries passed by the
application.
If we want to allow more flexibility on which gettext domain should be
used for these entries, new API will be needed.
https://bugzilla.gnome.org/show_bug.cgi?id=750322
Add a new section to the main GSettings documentation which documents
the best practices for integrating GSettings into an autoconf/automake
build system using the GLIB_GSETTINGS macro.
Some of this material was adapted from the migrating-gconf.xml guide.
https://bugzilla.gnome.org/show_bug.cgi?id=741788
* Only check __OBJECT_ATTRIBUTES_DEFINED and __UNICODE_STRING_DEFINED
on MinGW (MSVC doesn't have these)
* MSVC: disable:4005 when including windows.h and ntstatus.h
* Move NTAPI cconv into the parens with the NtQueryKeyFunc
* Fix return values in some functions
https://bugzilla.gnome.org/show_bug.cgi?id=734888
- On first call scan the registry, collect information about URI protocols,
file extensions, applications and handlers, store that as a set of
interconnected structures in several hash tables
- Watch the registry keys, re-scan the registry when any one of them changes.
https://bugzilla.gnome.org/show_bug.cgi?id=666831
Use the newly added g_settings_schema_list_keys() API instead of
g_settings_list_keys() in order to list keys.
Doing this allows the 'list-keys' command to work without creating a
GSettings object, which is more efficient. It also means that we don't
have to provide a (meaningless and ignored) path when listing keys on
relocatable schemas.
While we're at it, update the 'range' command not to require creation of
a GSettings object, in a similar way.
https://bugzilla.gnome.org/show_bug.cgi?id=740308
The list of keys in a GSettings object depends entirely on the schema,
so it makes sense to expose this API there.
Move the implementation out of gsettings.c and into gsettingsschema.c,
replacing the earlier with a simple call to the new location.
We don't do the same for children because the children can change.
https://bugzilla.gnome.org/show_bug.cgi?id=740308
Cancellation of GPollFileMonitor is now handled correctly (in the sense
that no further signals will follow) but let's be extra paranoid and
disconnect our handler anyway, for good measure.
https://bugzilla.gnome.org/show_bug.cgi?id=739424
GPollFileMonitor emits CHANGES_DONE_HINT after CHANGED signals, but it
doesn't check to ensure that the file monitor wasn't cancelled before it
does that.
If the original signal caused the monitor to be unreffed, cancelled and
destroyed, we would still end up emitting an extra signal on it.
Avoid that by checking first for cancellation.
https://bugzilla.gnome.org/show_bug.cgi?id=739424
Removed all mentions of GLib file name encoding referring to
the environment strings. The env var content has no defined relation
to GLib's notion of filename encoding, or any encoding whatsoever.
It would be wrong to pass all UTF-8 strings through
g_filename_from_utf8() in order to put them into the environment,
for one thing.
https://bugzilla.gnome.org/show_bug.cgi?id=738185
DBus has recently introduced new message flag
DBUS_HEADER_FLAG_ALLOW_INTERACTIVE_AUTHORIZATION, which tells that
caller is willing to wait for unspecified amount of time for the call
to return, as the service may perform interactive authorization (e.g.
using polkit).
https://bugzilla.gnome.org/show_bug.cgi?id=739616
In order to maintain a logical stream of events, we need to make sure we
flush and queued change notifications before responding to any requests
for information from clients.
If we don't do this, it's possible that we emit an 'add' event that was
queued at the time of a 'DescribeAll' call _after_ the reply to that
call (which already contained the description of the new action).
In practice, this is not only logically incorrect, but it can also cause
problems. If a change to action 'state' or 'enabled' occurs after the
DescribeAll but before the signal has been dispatched, it will be
ignored because an 'add' signal is already pending. When that add
signal is sent, it will contain the correct data, but the receiver will
ignore it because it already saw the action in the DescribeAll reply.
https://bugzilla.gnome.org/show_bug.cgi?id=749693
This is a hack for GLocalFileInfo to correctly get icons for directories.
Without this change content type for any W32 directory is NULL
(because there's no registry entry for "inode/directory" by default,
and in any way there's no file extension that means "directory" to put there),
and GLocalFileInfo uses content type to grab icons.
https://bugzilla.gnome.org/show_bug.cgi?id=748727
The code here was returning gtk-directory and similar names as
fallback, with a comment claiming that these are 'builtin gtk'.
But they aren't, anymore, so just return the standard names.
This code used to look at the SCM_CREDENTIALS and ignore every message
not from uid 0. However, when user namespaces are in use this does not
work, as if uid 0 is not mapped you get overflowuid instead. Right now
this means we ignore all messages in such user namespaces and glib
apps hang on startup.
We can't look at pids either, as pid 0 is returned for processes
outside your pid namespace.
Instead the correct approach is to look at the sending sockaddr and
if the port id (nl_pid) is zero, then its from the kernel.
Source:
http://lists.linuxfoundation.org/pipermail/containers/2015-May/036032.htmlhttps://bugzilla.gnome.org/show_bug.cgi?id=750203
Instead of just dropping address types that we're not specifically
handling we return a GNativeSocketAddress which is just a dummy
container for the stuct sockaddr.
https://bugzilla.gnome.org/show_bug.cgi?id=750203
GListStore requires that item-type be derived from GObject, so specify
that the type of the item parameters is GObject so the functions can be
used via gobject-introspection.
Add a scope parameter for the callback used during insert_sorted.
Previously, we waited up to 0.5s, but that can fail on slow
architectures like ARM; now we wait up to 60s in 0.1s increments.
Patch originally by Simon McVittie <simon.mcvittie@collabora.co.uk>,
modified by Iain Lane to be called earlier, to catch all testcases in a
particular test.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=724113
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Acked-by: Matthias Clasen <mclasen@redhat.com>
We previously waited 0.25s, which should be enough even on slow machines,
but you never know; but we also now wait in 0.1s increments, so this test
should actually be faster now.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=724113
Acked-by: Matthias Clasen <mclasen@redhat.com>
I searched all files that mention g_test_run, and replaced most
g_print() calls. This avoids interfering with TAP. Exceptions:
* gio/tests/network-monitor: a manual mode that is run by
"./network-monitor --watch" is unaffected
* glib/gtester.c: not a test
* glib/gtestutils.c: not a test
* glib/tests/logging.c: specifically exercising g_print()
* glib/tests/markup-parse.c: a manual mode that is run by
"./markup-parse --cdata-as-text" is unaffected
* glib/tests/testing.c: specifically exercising capture of stdout
in subprocesses
* glib/tests/utils.c: captures a subprocess's stdout
* glib/tests/testglib.c: exercises an assertion failure in g_print()
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=725981
Reviewed-by: Colin Walters <walters@verbum.org>
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
This stops it from interfering with structured stdout such as TAP.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=725981
Reviewed-by: Colin Walters <walters@verbum.org>
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
This avoids any possibility of interfering with test syntax (such as
TAP) on stdout. TAP specifically does not parse stderr.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=725981
Reviewed-by: Colin Walters <walters@verbum.org>
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
When running the nonce-tcp and tcp-anonymous tests in one run
of gdbus-peer, or running one of them twice via command-line options
"-p /gdbus/tcp-anonymous -p /gdbus/tcp-anonymous", the one run second
would sometimes fail to connect with ECONNRESET.
Adding more debug messages revealed that in the successful case,
g_main_loop_run() was executed in the server thread first:
# tcp-anonymous: server thread: listening on tcp:host=localhost,port=53517
# tcp-anonymous: server thread: starting server...
# tcp-anonymous: server thread: creating main loop...
# tcp-anonymous: server thread: running main loop...
# tcp-anonymous: main thread: trying tcp:host=localhost,port=53517...
# tcp-anonymous: main thread: waiting for server thread...
but in the failing case, the main thread attempted to connect
before the call to g_main_loop_run() in the server thread:
# tcp-anonymous: server thread: listening on tcp:host=localhost,port=40659
# tcp-anonymous: server thread: starting server...
# tcp-anonymous: server thread: creating main loop...
# tcp-anonymous: main thread: trying tcp:host=localhost,port=40659...
# tcp-anonymous: server thread: running main loop...
(The log message "creating main loop" was immediately before
create_service_loop(), and "running main loop" was immediately
before g_main_loop_run().)
To ensure that the GDBusServer has a chance to start accepting
connections before the main thread tries to connect to it, do not
tell the main thread about the service_loop immediately, but instead
defer it to an idle.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=749079
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Philip Withnall <philip.withnall@collabora.co.uk>
This test originally did not connect to the bus, which meant it was
omitted from commits like 415a8d81 that made sure none of GLib tests
rely on the presence of an existing session bus. (In particular,
Debian autobuilders don't have a session bus.)
When test_double_array() was added, environments like the Debian
autobuilders didn't catch the fact that this test relied on having a
session bus, because it is often skipped in minimal environments
due to its libdbus-1 dependency.
We don't actually need to connect to a dbus-daemon here: it's enough
to convert the message from GVariant to D-Bus serialization, and
back into an in-memory representation through libdbus. That's what
check_serialization() does, and I've verified that when I re-introduce
bug #732754 by reverting commits 627b49b and 2268628 locally, this
test still fails.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=744895
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Colin Walters <walters@verbum.org>
The changed variable was previously uninitialised in the path where the
rate limit was actually changed. This could result in the
GObject::notify signal not getting emitted.
Spotted by Coverity.
CID: #1296516https://bugzilla.gnome.org/show_bug.cgi?id=748834
The third parameter of the thumnail_verify() function had been updated to
const GLocalFileStat, so update the thumbnail-verification test likewise
so that the test works properly on all supported platforms.
https://bugzilla.gnome.org/show_bug.cgi?id=711547
Always run the full algorithm for a given mime type before considering
fallback types.
This includes considering installed applications capable of handling a
particular mimetype, even if such an app is not explicitly marked as
default, and there is a default app for a less-specific type.
Specifically, this often helps with cases of installing apps that can
handle a particular subtype of text/plain. We want to take those apps
in preference to a generic text editor, even if that editor is listed as
the default for text/plain and there is no default listed for the more
specific type.
Because of the more holistic approach taken by the algorithm, it is now
more complicated, but it also means that we can do more work while
holding the lock. In turn, that lets us avoid duplicating some strings,
which is nice.
https://bugzilla.gnome.org/show_bug.cgi?id=744282
If g_dbus_message_to_blob() fails at all, it will leak its mbuf. Spotted
by running the gdbus-serialization test under Valgrind — so there is a
justification for leak-free tests after all!
In path_rule_matches(), the given paths may be of 0-length. Do not
access memory before the array in those case. This is for example
triggered by:
test_match_rule (con, G_DBUS_SIGNAL_FLAGS_MATCH_ARG0_PATH, "/", "", FALSE);
in test_connection_signal_match_rules().
This bug was found thanks to GCC AddressSanitizer.
https://bugzilla.gnome.org/show_bug.cgi?id=745745
Passing an nonsense string for the --dest argument can lead
to a segfault of gdbus. Thats not nice, so use our existing
validation function for bus names here.
https://bugzilla.gnome.org/show_bug.cgi?id=747541
Make sure error handling on repeated <summary> and <description> is
being done properly, not resulting in glib-compile-schemas throwing a
critical.
https://bugzilla.gnome.org/show_bug.cgi?id=747542
Fix a couple of issues in error handling in glib-compile-schemas.
The first problem is that, in case of repeated <summary> or
<description> tags we were still allocating a GString which was never
being freed (due to the throwing of the error resulting in immediate
termination of the parse).
The second problem is that if the repeated <summary> tag also had
attributes, we would attempt to set the GError twice.
https://bugzilla.gnome.org/show_bug.cgi?id=747542
Bug 747209 introduced an error when multiple <summary> or <description>
tags are found for a single key in a GSettings schema. This check
should have been present from the start, but it was left out because the
schema compiler doesn't include these items in the cache file. Even
still -- part of the schema compiler's job is validation, and it should
be enforcing proper syntax here.
Repeated <summary> and <description> tags are a semi-common problem when
intltool has been misconfigured in the build system of a package, but
it's possible to imagine mistakes being made by hand as well.
The idea is that these problems would be caught during the build of a
package and maintainers would be forced to fix their build systems.
An unintended side-effect of this change, however, is that the schema
compiler started ignoring already-installed schemas that contained these
problems, when rebuilding the cache. This means that the installation
of _any_ application would cause the regeneration of the entire cache,
with these already-installed applications being excluded. Without the
schema in the cache, the application would crash on next startup.
The validation check in the gsettings m4 macro passes --strict to the
compiler, which is not used when rebuilding the cache after
installation. Pass this flag down into the parser and only throw the
error in case --strict was given. This will result in the (desired)
build failure without also causing already-installed apps to stop
functioning.
This means that we will not get even a warning about the invalid schema
file in the already-installed case, but that's fine. There is no sense
spamming the user with these messages when they are already quite fatal
for the developer at build time.
https://bugzilla.gnome.org/show_bug.cgi?id=747472
Commit f10b655 removed the inclusion of gasyncresult.h from gdbusproxy.c,
but gdbusproxy.c uses g_async_result_get_source_object(), which caused a
build warning/error. Fix that.
The gdbus GTask port introduced a deadlock because some code had been
using g_simple_async_result_complete_in_idle() to ensure that the
callback didn't run until after a mutex was unlocked, but in the gtask
version, the callback was being run immediately. Fix it to drop the
mutex before calling g_task_return*(). Also, tweak
tests/gdbus-connection to test this.
https://bugzilla.gnome.org/show_bug.cgi?id=747349
Add support for copying session data between client connections.
This is needed for implementing FTP over SSL. Most servers use a separate
session for each control connection and enforce sharing of each control
connection's session between the related data connection.
Copying session data between two connections is needed for two reasons:
1) The data connection runs on a separate port and so has a different
server_identity which means it would not normally share the session with
the control connection using the session caching currently implemented.
2) It is typical to have multiple control connections, each of which
uses a different session with the same server_identity, so only one of
these sessions gets stored in the cache. If a data connection is opened,
(ignoring the port issue) it may try and reuse the wrong control
connection's session, and fail.
This operation is conceptually the same as OpenSSL's SSL_copy_session_id
operation.
https://bugzilla.gnome.org/show_bug.cgi?id=745255
This allows the caller to know when a socket has been bound so that
it can for instance set the SO_SENDBUF and SO_RECVBUF socket options
before listen is called
https://bugzilla.gnome.org/show_bug.cgi?id=738207
GTask used a 10-thread thread pool for g_task_run_in_thread() /
g_task_run_in_thread_sync(), but this ran into problems when task
threads blocked waiting for another g_task_run_in_thread_sync()
operation to complete. Previously there was a workaround for this, by
bumping up the thread limit when that case was detected, but deadlocks
could still happen if there were non-GTask threads involved. (Eg, task
A sends a message to thread X and waits for a response, but thread X
needs to complete task B in a thread before returning the response to
task A.)
So, allow GTask's thread pool to be expanded dynamically, by watching
it from the glib worker thread, and growing it (at an
exponentially-decreasing rate) if too much time passes without any
tasks completing. This should solve the deadlocking problems without
causing sudden breakage in apps that assume they can queue huge
numbers of tasks at once without consequences.
https://bugzilla.gnome.org/show_bug.cgi?id=687223
This schema compiler was completely ignoring <summary> and
<description> tags. Unfortunately, there are modules out there
who merge translations for these back in, with xml:lang. And
this is giving dconf-editor a hard time. Since this is not
how translations of schemas are meant to be done, just
reject such schema files.
Also add tests exercising the new error handling.
https://bugzilla.gnome.org/show_bug.cgi?id=747209
glib-compile-resources was guessing a filename ending
in .c when generating sources, but did not do the same
for headers. Fix it so it generates a .h file when
guessing the filename for headers.
https://bugzilla.gnome.org/show_bug.cgi?id=746753
The hash table stores the list of unmatched IN_MOVE_FROM events, but we
were removing entries from it when popping IN_MOVE_TO events.
Fix that up to correct a crash in nautilus due to the assertion failure
below.
https://bugzilla.gnome.org/show_bug.cgi?id=746749
Due to a typo, a rename reported via a pair of delete/create events (due
to the watcher not giving the flag for moves to be paired) was
accidentally reported as being created with the old name instead of the
new name.
Fix that.
We declare the typedefs for GListModel and GListStore in giotypes.h, as
a matter of convention. This is not actually required, since the
typedef is emitted as part of the G_DECLARE_* macros.
The giotypes.h approach is only used to avoid cyclic dependencies
between headers, which is not a problem in this case.
Type redefinition is a C11 feature, and although it was around in some
compilers before then, gcc 4.2.1 (from 2007) is apparently still in wide
use, being the default compiler for OpenBSD.
Eventually, we will probably hit a case where we actually need to
redefine a type, but since we're not there yet, let's back off a bit.
This WIP patch moves the Windows Directory Monitoring code to the new
GLocalFileMonitor mechanism, and adds file monitoring in the process.
Progress from previous patch:
-File renames are now properly supported, but G_FILE_MONITOR_EVENT_MOVED_IN
and G_FILE_MONITOR_EVENT_MOVED_OUT needs to be investigated, as
ReadDirectoryChangesW() seems to send FILE_ACTION_REMOVED when a file is
moved out of a directory.
-Events are handled for both the long and short (8.3) variants of the
filenames, and files monitored will report changes when it is changed
via its short or long filenames.
Things to be done:
-Perhaps find out about attribute changes in files in a monitored
directory; if a file is monitored, attribute changes are correctly
handled.
-Investigate on G_FILE_MONITOR_EVENT_MOVED_OUT,
G_FILE_MONITOR_EVENT_MOVED_IN, G_FILE_MONITOR_EVENT_PRE_UNMOUNT,
G_FILE_MONITOR_EVENT_UNMOUNTED.
-Investigate on the "boredom" algoritm, and see how we can do it on
Windows.
https://bugzilla.gnome.org/show_bug.cgi?id=730116
Completely rewrite the FAM file monitor. Major changes:
- now runs in the worker thread
- dispatches events in a threadsafe way via GFileMonitorSource
- uses unix fd source instead of a GIOChannel
- is now simple enough to fit into one short file
This is the bare minimal effort. This seems not to crash immediately,
but it definitely needs some better testing.
The backend is not in good shape. It could use some serious work.
Use the "interesting" value from g_file_monitor_source_handle_event() to
decide if we're currently being flooded by a stream of boring events.
The main case here is when one or more files is being written to and the
change events are all being rate-limited in the GFileMonitor frontends.
In that case, we become "bored" with the event stream and add a backoff
timeout. In the case that it is exactly one large file being written
(which is the common case) then leaving the event in the queue also lets
the kernel perform merging on it, so when we wake up, we will only see
the one event. Even in the case that the kernel is unable to perform
merging, the context switch overhead will be vastly reduced.
In testing, this cuts down on the number of wake ups during a large file
copy, by a couple orders of magnitude (ie: less than 1% of the number of
wake ups).
Return an "interesting" boolean from the event handler function on
GFileMonitorSource.
An event was "interesting" if it will result in a signal actually being
dispatched to the user. It is "uninteresting" if it only hit an
already-dirty rate limiter.
We will use this information to do some backing off in the backends when
faced with a flood of uninteresting events.
We generally assume that an IN_CREATE event is the start of a series of
events in which another process is doing this:
fd = creat (...) -> IN_CREATE
write (fd, ..) -> IN_MODIFY
write (fd, ..) -> IN_MODIFY
close (fd) -> IN_CLOSE_WRITE
and as such, we use the CHANGES_DONE_HINT event after CREATED in order
to show when this sequence of events has completed (ie: when we receive
IN_CLOSE_WRITE when the user closes the file).
Renaming a file into place is handled by IN_MOVED_FROM so we don't have
to worry about that.
There are many other cases, however, where a new file 'appears' in a
directory in its completed form already, and the kernel reports
IN_CREATE. Examples include mkdir, mknod, and the creation of
hardlinks. In these cases, there is no corresponding IN_CLOSE_WRITE
event and the CHANGES_DONE_HINT will have to be emitted by an arbitrary
timeout.
Try to detect some of these cases and report CHANGES_DONE_HINT
immediately.
This is not perfect. There are some cases that will not be reliably
detected. An example is if the user makes a hardlink and then
immediately deletes the original (before we can stat the new file).
Another example is if the user creates a file with O_TMPFILE. In both
of these cases, CHANGES_DONE_HINT will still eventually be delivered via
the timeout.
Remove all event merging and dispatch logic from GFileMonitor. The only
implementation of GFileMonitor outside of glib is in gvfs and it already
does these things properly.
Get rid of GLocalDirectoryMonitor. We will use a single class,
GLocalFileMonitor, for both directory and file monitoring. This will
prevent every single backend from having to create two objects
separately (eg: ginotifydirectorymonitor.c and ginotifyfilemonitor.c).
Introduce GFileMonitorSource as a thread-safe cross-context dispatch
mechanism. Put it in GLocalFileMonitor. All backends will be expected
to dispatch via the source and not touch the GFileMonitor object at all
from the worker thread.
Remove all construct properties from GLocalFileMonitor and remove the
"context" construct property from GFileMonitor. All backends must now
get the information about what file to monitor from the ->start() call
which is mandatory to implement.
Remove the implementation of rate limiting in GFileMonitor and add an
implementation in GLocalFileMonitor. gvfs never did anything with this
anyway, but if it wanted to, it would have to implement it for itself.
This was done in order to get the rate_limit field into the
GFileMonitorSource so that it could be safely accessed from the worker
thread.
Expose g_local_file_is_remote() internally for NFS detection.
With the "is_remote" functionality exposed, we can now move all
functions for creating local file monitors to a proper location in
glocalfilemonitor.c
Port the inotify backend to adjust to the changes above. None of the
other backends are ported yet. Those will come in future commits.
Remove the hardwired 1 second event queue logic from inotify-kernel and
replace it with something vastly less complicated.
Events are now reported as soon as is possible instead of after a
delay.
We still must delay IN_MOVED_FROM events in order to look for the
matching IN_MOVED_TO events, and since we want to report events in order
this means that events behind those events can also be delayed. We
limit ourselves, however:
- no more than 100 events can be delayed at a time
- no event can be delayed by more than 10ms
https://bugzilla.gnome.org/show_bug.cgi?id=627285
Add a new internal constructor for GLocalFile (which itself is private).
This new constructor allows creating a GLocalFile from a dirname and a
basename, assuming that the dirname is already in canonical form and the
basename is a regular basename.
This will be used for creating GLocalFile instances from the file
monitoring code (for signal emissions).
For all of the effort spent ensuring that this algorithm would be
correctly threadsafe, I messed up the order of operations within a
single thread when porting to the new approach.
Fix that up.
Also: fix some overzealous asserting in the testcases. Since shutdown
is now lazy, we can never surely say !is_running at any particular point
in time.
This can be used to query whether the task has completed, in the sense
that it has had a result set on it, and has already – or will soon –
invoke its callback function.
Notifications for this property are emitted immediately after the task’s
main callback, in the same main context as that callback. This allows
for multiple bits of code to listen for completion of the GTask, which
opens the door for blocking on cancellation of the GTask and improved
handling of ‘pending’ behaviour.
https://bugzilla.gnome.org/show_bug.cgi?id=743636
g_socket_client_add_application_proxy() claimed "When the indicated
proxy protocol is returned by the #GProxyResolver, #GSocketClient will
consider this protocol as supported but will not try to find a #GProxy
instance to handle handshaking." But in fact, it did the checks in the
wrong order, so GProxy proxies ended up overriding
application-specified ones. Fix that.
Also, simplify the code a bit by making use of g_hash_table_add() and
g_hash_table_contains().
https://bugzilla.gnome.org/show_bug.cgi?id=733876
Currently, the Windows code use Winsock2-specific APIs to try to emulate
calls such as inet_pton(), inet_ntop() and if_nametoindex(), which may not
do the job all the time. On Vista and later, Winsock2 does provide a
proper implementation for these functions, so we can use them if they exist
on the system, by querying for them during g_networking_init(). Otherwise,
we continue to use the original code path for these, in the case of XP and
Server 2003.
This enables many of the network-address tests to pass on Windows as a
result, when the native Winsock2 implementations can be used.
https://bugzilla.gnome.org/show_bug.cgi?id=730352
Check the IPv6 addresses on Windows, as we need to reject those that have
brackets/ports around them as valid addresses in this form would have been
accepted during the call to g_inet_address_new_from_string ().
https://bugzilla.gnome.org/show_bug.cgi?id=730352
There was a theoretical deadlock between the worker trying to emit a
signal at the same time as we were waiting for it to shutdown the
notification (while holding the lock).
The deadlock was particularly annoying because we didn't really need to
wait for the shutdown and because it wasn't possible to signals to
arrive while waiting for a start. Attempting to deal with start and
stop in an asymmetric way could have lead to other weird situations,
however.
Drop the lock while waiting for the worker thread to start. This means
that we face the possibility of multiple waiters on the cond at the same
time, so we need to make more of a state machine.
https://bugzilla.gnome.org/show_bug.cgi?id=742599
GUnixMountMonitor was not threadsafe before. It was a global singleton
which emitted signals in the first thread that happened to construct it.
Move it to a per-context singleton model where each GMainContext gets
its own GUnixMountMonitor. Monitor for the changes from the GLib worker
thread and dispatch the results to each context with an active monitor.
https://bugzilla.gnome.org/show_bug.cgi?id=742599
Deprecate g_unix_mount_monitor_set_rate_limit() and turn it into a
no-op.
This function doesn't behave as advertised. It only controls rate
limiting for filesystem-based monitors. It has no impact over reporting
mount changes on Linux, for example, because those are based on polling
for changes in /proc (which doesn't use filesystem monitors). It also
has no impact on Mac OS because a library interface is used there.
This was added in https://bugzilla.gnome.org/show_bug.cgi?id=521946 in
order to be used by HAL, which is effectively dead. udisks no longer
uses this code at all.
https://bugzilla.gnome.org/show_bug.cgi?id=742599
This is a singleton, but we have a function called _new() to get it.
What's worse is that the documentation makes no mention of this, and
actually specifically says that a new monitor will be created each time.
https://bugzilla.gnome.org/show_bug.cgi?id=742599
Add a new internal helper called GContextSpecificGroup.
This is a mechanism for helping to maintain a group of context-specific
monitor objects (eg: GAppInfoMonitor, GUnixMountMonitor).
https://bugzilla.gnome.org/show_bug.cgi?id=742599
If someone explicitly calls g_application_quit() then don't attempt to
drain the mainloop of remaining sources.
This allows applications with 100% CPU utilisation to quit reliably.
https://bugzilla.gnome.org/show_bug.cgi?id=744876
We install win32-software/autorun.exe (as test data for mime scanning)
only on UNIX builds, so don't attempt to chmod it on 'make install'
unless we're on UNIX.
I love Emacs keyboard macros, used them to convert the list of
defines cleverly into a list of tests, then iterated and filled in
the necessary constructor arguments.
After ::shutdown, run the mainloop until all pending activity is
handled, before returning from run().
Among other things, this gives a chance for destroyed windows to be
properly withdrawn from the windowing system.
https://bugzilla.gnome.org/show_bug.cgi?id=744876
This is *significantly* more pleasant to use from C (while handling
errors and memory cleanup).
While we're here, change some ugly, leaky code in
tests/desktop-app-info.c to use it, in addition to a test case
in tests/file.c.
https://bugzilla.gnome.org/show_bug.cgi?id=661554
g_application_bind_busy_property() had the restriction that only one
property can be bound per object, so that NULL could be used to unbind.
Even though this is enough for most uses, it is a weird API.
Lift that restriction and add an explicit unbind function.
https://bugzilla.gnome.org/show_bug.cgi?id=744565
Add an implementation of non-thread-emulated async close of a GIOStream
if either of the underlying stream objects support it.
This prevents us from calling close() functions from another thread on
an object that may not be expecting that. It also allows us to skip the
thread entirely in case our objects support a pure async close.
https://bugzilla.gnome.org/show_bug.cgi?id=741630
Add an internal helper to find out if close_async() is implemented via
threads using the default implementation in the base class.
We will use this to decide if we should do a 'pure async' close of a
GIOStream or not.
https://bugzilla.gnome.org/show_bug.cgi?id=741630
delayed_close_free() calls g_object_unref() on a variable that is
expected to possibly contain NULL (as indicated by the fact that the
NULL case is handled in my_slow_close_output_stream_close_async()).
This is dead code right now (due to a bug in GDBus), which is why it
isn't actually causing a failure. It should still be fixed, however.
https://bugzilla.gnome.org/show_bug.cgi?id=743990
GApplication set the prgname to the application's id when it was running
in service mode. This broke with the addition of new --app-id option,
because g_set_prgname() was called before parsing the options. Calling
it after option parsing doesn't work, because GOptionContext sets
prgname to argv[0] unconditionally.
Instead of changing the semantics of GOptionContext, simply remove this
functionality from GApplication. It is very unusual to have the prgname
set to the app id instead of the binary's name and might confuse people
when looking at logs etc.
When overriding local_command_line() from a subclass,
g_option_context_parse() might never be invokded. Thus, continue setting
the prgname to argv[0] in GApplication.
https://bugzilla.gnome.org/show_bug.cgi?id=743933
Balancing g_application_{un,}mark_busy() is non-trivial in some cases.
Make it a bit more convenient by allowing to bind multiple boolean
properties (from different objects) to the busy state. As long as these
properties are true, the application is marked as busy.
https://bugzilla.gnome.org/show_bug.cgi?id=744565
Add g_list_store_insert_sorted() which takes a GCompareDataFunc to
decide where to insert. This ends up being a very trivial function,
thanks to GSequence.
https://bugzilla.gnome.org/show_bug.cgi?id=743927
Make sure that we only match the _get_type() function name by
restricting the regexp to matching [A-Za-z0-9_]. We were matching on .*
before which means that if we had two _get_type() functions appearing on
a single line then we would get everything in between them included (by
the default rule of '*' being greedy).
This affected G_DECLARE_*_TYPE which puts several uses of _get_type()
into a single line.
GListModel is an interface that represents a dynamic list of GObjects.
Also add GListStore, a simple implementation of GListModel that stores
all objects in memory, using a GSequence.
https://bugzilla.gnome.org/show_bug.cgi?id=729351
Currently the only way to set a state hint on an action is through a
subclass; add a g_simple_action_set_state_hint() method so that this
becomes easier for clients that already use GSimpleAction.
https://bugzilla.gnome.org/show_bug.cgi?id=743521
When implementing blocking operations on top of
nonblocking sockets we should always first try to
perform the operation and then if needed handle
EAGAIN and wait with g_socket_wait_condition.
This is an optimization since we avoid calling
wait condition when it is not needed, but most
importantly this fixes hangs on win32 where some
events (in particular FD_WRITE) are only emitted
after the operation fails with EWOULDBLOCK.
https://bugzilla.gnome.org/show_bug.cgi?id=732439https://bugzilla.gnome.org/show_bug.cgi?id=741707
Add a unit test that checks g_socket_new_from_fd by creating
a gsocket, obtaining its fd, duplicating the fd and then creating
a gsocket from the new fd. This shows a hang on win32 since the
gsocket created from the fd never receives the FD_WRITE event
because we wait for the condition without first trying to write
and windows signals the condition only after a EWOULDBLOCK error.
https://bugzilla.gnome.org/show_bug.cgi?id=741707
We were asking for properties on NM's dbus interface, but if NM is not
running then there won't be any. Check if the name has an owner before
doing anything to it.
https://bugzilla.gnome.org/show_bug.cgi?id=741653
In g_file_make_directory_with_parents(), the my_error variable is used
for several different purposes throughout the whole function, not all of
which are obvious. This explains the situation with some comments.
https://bugzilla.gnome.org/show_bug.cgi?id=719455
Allows sending of multiple messages (packets, datagrams)
in one go using sendmmsg(), thus drastically reducing the
number of syscalls when sending out a lot of data, or when
sending out the same data to multiple recipients.
https://bugzilla.gnome.org/show_bug.cgi?id=719646
Fix two problems:
1) If g_socket_service_stop is called before the accept call is requeued,
then the reference count won't decrease and this code will hang forever:
while (G_OBJECT (service)->ref_count == ref_count)
g_main_context_iteration (NULL, TRUE);
2) Sometimes the testcase fails (maybe 1 in 200 times for me):
GLib-GIO:ERROR:socket-listener.c:73:connection_cb: assertion failed
(G_OBJECT (service)->ref_count == 2): (3 == 2)
Aborted (core dumped)
The problem is that depending on ordering, cancellation of the async
listener can require further main context iterations before it releases
the reference on the socket service. Furthermore, in some cases, it
requires at least one iteration.
https://bugzilla.gnome.org/show_bug.cgi?id=712570
Add a property to GNetworkMonitor indicating the level of network
connectivity: none/local, limited, stuck behind a portal, or full.
The default implementation just returns none or full depending on the
value of is-available.
https://bugzilla.gnome.org/show_bug.cgi?id=664562
Add G_IO_ERROR_CONNECTION_CLOSED as an alias for
G_IO_ERROR_BROKEN_PIPE, and also return it on ECONNRESET.
It doesn't really make sense to try to distinguish EPIPE and
ECONNRESET at the GLib level, since the exact choice of which error
gets returned in what conditions depends on the OS. Given that, we
ought to map the two errors to the same value, and since we're already
mapping EPIPE to G_IO_ERROR_BROKEN_PIPE, we need to map ECONNRESET to
that too. But the existing name doesn't really make sense for sockets,
so we add a new name.
https://bugzilla.gnome.org/show_bug.cgi?id=728928
This is a convenience method for creating a GNetworkAddress which is
guaranteed to return IPv4 and IPv6 loopback addresses. The program
cannot guarantee that 'localhost' will resolve to both types of
address, so programs which wish to connect to a local service over
either IPv4 or IPv6 must currently manually create an IPv4 and another
IPv6 socket, and detect which of the two are working. This new API
allows the existing GSocketConnectable machinery to be used to
automate that.
Based on a patch from Philip Withnall.
https://bugzilla.gnome.org/show_bug.cgi?id=732317
g_settings_has_signal_handlers() checks whether any of the signals has
pending handlers. However, g_signal_has_handler_pending() matches on
exact detail, even when passing 0. Subscribing to one of GSettings'
signals with a detail will fail this check and never connect to the
backend.
Fix this by calling has_handler_pending() with the key as detail as
well.
https://bugzilla.gnome.org/show_bug.cgi?id=740848
Add a GSocketListener test program. Currently the only test is a
regression test for bug 712570 (based on a standalone bug reproducer
provided by Ross Lagerwall).
If all users of a GThreadedSocketService release their references to the
service while a connection thread is running, the thread function will
release the last reference to the service which causes the finalize to
deadlock waiting for all threads to finish (because it's called from the
thread function).
To fix this, don't wait for all threads to finish in the service's
finalize method. Since the threads hold a reference to the service,
finalize should only be called when all threads are finished running (or
have unrefed the service and are about to finish).
https://bugzilla.gnome.org/show_bug.cgi?id=712570
If SSL 3.0 has been disabled (at the host, application, or library
level), then the "use-ssl3" property becomes a "fail-immediately"
property.
Despite the name, the point of the property wasn't really specifically
to use SSL 3.0; it was to allow fallback when talking to broken
servers that do SSL/TLS negotiation incorrectly and break when they
see unexpectedly-high version numbers. So if we can't fall back to SSL
3.0, then the "use-ssl3" property should fall back to TLS 1.0 instead
(since there are hosts that will reject a TLS 1.2 handshake, but
accept a TLS 1.0 one).
glib-networking is being updated to implement that behavior, so update
the documentation here.
https://bugzilla.gnome.org/show_bug.cgi?id=738633
In commit 8ff5668, we are subscribing the GSettings backend later, but this
meant that we need to initialize cache_lock earlier, as we might try to
use that lock before a change notification is issued to subscribe the
backend, which would then cause an access violation if we are trying to
read GSettings values, as that lock is used to access the Windows Registry.
Initialize cache_lock once we initialize the GSettings Registry backend,
and delete it upon finalize, so that g_settings_read_from_backend() can
proceed normally, even if the GSettings backend is not yet subscribed.
https://bugzilla.gnome.org/show_bug.cgi?id=740413
GSettings objects begin watching for changes as soon as they are created
in order that they can emit the "changed" signal.
In the case of dconf, if we want to be able to emit the changed signal,
we need to go on the bus and add some match rules. This requires
creating the dconf helper thread and also requires initialising GDBus
(which creates another thread).
Some users of GSettings are never interested in the "changed" signal.
One of these users is the glib-networking code that gets run every time
a new network connection is created.
Some users are reporting that they are annoyed that simply establishing
a network connection would spawn two extra threads and create a D-Bus
connection.
In order to avoid doing unnecessary work for these simple uses, delay
the subscription until we know that we will actually need to do it.
We do this in a simple way, using a simple argument: in order for the
user to care that a value changed then they must have:
1) watched for a change signal; and then
2) actually read a value
If the user didn't actually read a value then they cannot possibly be
interested in if the value changed or not (since they never knew the old
value to begin with and therefore would be unable to observe that it
ever changed, since they have nothing to compare the new value with).
This really is a behaviour change, however, and it does impact at least
one user: the 'monitor' functionality of the GSettings commandline tool,
which is interested in reporting changes without ever having known the
original values. We add a workaround to the commandline tool in order
to ensure that it continues to function properly.
It's also possible to argue that it is completely valid to have read a
value and _then_ established a change signal connection under the
(correct) assumption that it would not have been possible to miss a
change signal by virtue of not having returned to the mainloop.
Although this argument is true, this pattern is extremely non-idiomatic,
and the problem is easily avoided by doing things in the usual order.
We never really talked about change notification in the overview
documentation for GSettings, so it seems like now is a good time to add
some discussion, including the new rules for when one can expect change
signals to be emitted.
https://bugzilla.gnome.org/show_bug.cgi?id=733791
This should already work according to the documentation, but doesn't
because main_options is consumed before the check in
g_application_parse_command_line().
Fix by moving the check for main_options up.
https://bugzilla.gnome.org/show_bug.cgi?id=740157
The win32 headers do:
#define interface struct
which is just evil and breaks other code that assumes it can use
"interface" as a variable name. gnetworking.h was supposed to be doing
"#undef interface" after including the win headers, but it did it too
soon, resulting in it getting redefined by a later include. Fix this.
https://bugzilla.gnome.org/show_bug.cgi?id=738551
g_tls_certificate_new_from_file() was only loading the complete chain
if it was fully valid, but we only meant to be validating that it
formed an actual chain (since the caller may be planning to ignore
other errors).
https://bugzilla.gnome.org/show_bug.cgi?id=729739
Fix a hang due to overflow by using unsigned numbers and explicitly
checking if the number overflows to zero. This also fixes the previous
logic which assigned an int which may be negative to an unsigned number
resulting in sign extension and strange results.
Use gsize rather than int to allow for large buffers on 64 bit machines.
https://bugzilla.gnome.org/show_bug.cgi?id=727988
Fix a hang due to overflow by using unsigned numbers and explicitly
checking if the number overflows to zero. This also fixes the previous
logic which assigned an int which may be negative to an unsigned number
resulting in sign extension and strange results.
Use gsize rather than int to allow for large streams on 64 bit machines.
https://bugzilla.gnome.org/show_bug.cgi?id=727988
There are two consistent interpretations that could be taken for memory
handling of the 'invocation' parameter passed to the method_call() virtual
function of GDBusInterfaceVTable
- A reference is passed (transfer full) to the method_call() virtual function,
and that reference is then passed (transfer full) to the return_value/error
functions on GDBusMethodInvocation.
- An internal reference is retained from the point where method_call() is called
until the return_value/error function is called.
Since the return_value/error functions were already marked (transfer full),
we use the first interpretation, annotate the invocation parameter of
method call as (transfer full) and describe this in the documentation, along
with the idea that you are always supposed to call one of the return_value/error
functions.
See bug 738122 for the leak this caused in GJS.
https://bugzilla.gnome.org/show_bug.cgi?id=738259
Clarify in the documentation that a GSource created with
g_cancellable_source_new() must be explicitly removed from its
GMainContext before the GCancellable can be finalised.
This could be a common way of leaking GCancellables.
https://bugzilla.gnome.org/show_bug.cgi?id=737259
da053e34 broke the tls-certificates test by requiring the backend to
implement g_tls_certificate_verify() (which the test TLS backend
didn't). Add a trivial implementation to make the test pass again;
we'll need something more complicated when we add tests that are
supposed to get errors.
So shortcut it.
I wrote this patch less as a performance optimization and more as a
clarification, so that people looking at the code can be assured of this
invariant.
https://bugzilla.gnome.org/show_bug.cgi?id=738374
These functions are inconsistent with our normal conventions in that
they set an output variable to a specified value, even in the case that
an error is thrown.
Document very clearly that this should be considered exceptional.
https://bugzilla.gnome.org/show_bug.cgi?id=737451
Similar to the previous patch, this commit contains a minor violation of
normal API conventions. See the explanation in the previous commit
message.
Heavily based on a patch from Ignacio Casal Quinteiro.
https://bugzilla.gnome.org/show_bug.cgi?id=737451
Add an asynchronous version of _read_all().
This API is not fully consistent with the normal expectations of a
non-asynchronous version. Consistency between the sync and async version is
probably more important.
The API will still bind correctly, but access to all functionality will
not be available: specifically, in the case of an error, higher level
languages will be unable to determine how many bytes were successfully
read before the error. Most users will probably not want to use this
information anyway, so this is OK -- and if they do need the
information, then they can just write the loop for themselves.
Heavily based on a patch from Ignacio Casal Quinteiro.
https://bugzilla.gnome.org/show_bug.cgi?id=737451
Commit e24e89b accidentally ironically introduced a typo when replacing
the code with symbolic contents. Specifically, "Added Associations" was
replaced with "Default Applications" when reading defaults.list, giving
a warning about the file containing a "Default Applications" group.
If this was intended, it should have not been lumped in with a cleanup.
This patch changes the behavior of the following functions:
g_tls_certificate_new_from_pem
g_tls_certificate_new_from_file
g_tls_certificate_new_from_files
If more than one certificate is found it will try to load the chain.
It is assumed that the chain will be in the right order (top-level
certificate will be the last one in the file). If the chain cannot be
verified, the first certificate in the file will be returned as before.
https://bugzilla.gnome.org/show_bug.cgi?id=729739
g_thread_pool_push() only returns an error if it fails to spawn a new
thread. However, it unconditionally adds the task to its worker queue,
so:
• if _any_ threads exist in the pool, the task will eventually be
handled; and
• if _no_ threads exist in the pool, the task will be handled if one
is eventually successfully spawned.
If no more threads are ever spawned, the process probably has bigger
problems than a single GTask which is taking forever to complete.
https://bugzilla.gnome.org/show_bug.cgi?id=736806
For the GPtrArray example, several variables declared on the same line
is harder to read and to work with (to move, remove or comment a single
variable declaration).
Some desktop file directories, like /usr/local/share/applications may be
missing on some systems.
When we try to inotify on these directories, this will result in a
every-4-seconds poll being setup which is quite bad.
This is an issue that should be fixed in inotify itself but the problem
is much larger there. For now, we can work around it in GDesktopAppInfo
by refusing to monitor missing directories.
We may get some spurious notifications of changes in the case that
/usr/local/share or /usr/local/share/applications is created without
actually adding desktop files, but spurious changes can already be
reported in other cases, so that's OK. We won't get (user-visible)
notification for a simple case of a completely unrelated file being
created (however we cannot avoid the wakeup in this case due to how
inotify works). That's probably pretty theoretical, though, since files
in /usr don't change much and for the home directory we're likely to
have at least ~/.config and ~/.local existing.
https://bugzilla.gnome.org/show_bug.cgi?id=736350
