This is an implementation of most of GContentType using the OS X
UTType APIs.
Missing at this point is an implementation of
g_content_types_get_registered() and g_content_type_guess_for_tree().
https://bugzilla.gnome.org/show_bug.cgi?id=734946
Previously, _kh_cancel_sub assumed that it only needed to call
_km_remove if sub did not exist in subs_hash_table. This is erroneous
because the complementary operation, _km_add_missing, can be called
from process_kqueue_notifications, in which context sub can *only* have
come from subs_hash_table.
Since _km_remove is implemented using g_slist_remove, which is
documented to be a noop if the list does not contain the element to be
removed, it is safe to call _km_remove unconditionally here.
https://bugzilla.gnome.org/show_bug.cgi?id=778515
g_settings_schema_source_get_default() is (transfer none), not (transfer
full).
Spotted by Marvin Schmidt.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=779265
On the warning/critical error handling paths for g_settings_set(), the
GVariant value was not ref-sunk, and the schema key was leaked. This
won’t affect code in production (unless it’s seriously buggy), but
eliminates some leaks from the error testing paths in the GSettings
tests.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=779265
Spotted while running `make check` under Valgrind. While it’s not
necessary to fix memory leaks in glib-compile-schemas (since it’s a
utility which runs briefly then exits), fixing them makes more
legitimate leaks in the Valgrind output more obvious, and means we can
be sure there aren’t leaks in the underlying GLib/GIO code which
glib-compile-schemas is calling.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=779265
When unregistered extension point (i.e. NULL pointer) is passed
to `g_io_extension_point_get_extensions`, it causes a segfault.
This commit adds an assertion, to prevent this.
https://bugzilla.gnome.org/show_bug.cgi?id=779183
Happens when the waiting-for-auth state is re-entered:
SERVER_STATE_WAITING_FOR_AUTH
|
v
G_DBUS_AUTH_MECHANISM_STATE_REJECTED
|
v
SERVER_STATE_WAITING_FOR_AUTH
Causing the previous `mech` pointer to get overwritten.
https://bugzilla.gnome.org/show_bug.cgi?id=778991
We're first getting the notification by its notify_id, but activating
the action afterwards could redraw it, leading to a dangling pointer.
Fix this by simply searching the list of active notifications again
after activating the action.
GNOME Builder's code was assuming that setting the launcher's
environ to NULL makes the subprocess have an empty environment, but in
fact the parent process's variables are still inherited because execv is
used instead of execve when envp is NULL. This commit clarifies the
documentation to make the behavior clear.
https://bugzilla.gnome.org/show_bug.cgi?id=778422
Add filesystem attribute to propagate time, when the metadata for the file
in "recent:///" was last changed. This attribute is needed for sorting
recent backend files in client applications.
https://bugzilla.gnome.org/show_bug.cgi?id=777507
This is small enough that it shouldn't cause problems on most machines
we support, but big enough to increase throughput on a lot of devices
and network protocols.
Note that the actual value is 256k minus malloc overhead, so that it
fits nicely in a 256k block (as suggested by Alexander Larsson).
See https://bugzilla.gnome.org/show_bug.cgi?id=773632https://bugzilla.gnome.org/show_bug.cgi?id=773823
It was suggested that the project files be moved here as we don't actually
need to go two directory layers from $(srcroot), and would help us to
standardize on things in the future across the board.
When performing the verify and building the error string there were two
possibilities of an infinite loop. The first is the missing twos-complement
to unset the bit in the filtered flags. The second is the lack of handling
G_SUBPROCESS_FLAGS_NONE which can return a valid GFlagsValue (and cannot
unset the bit since the value is zero).
This walks all known values in the GSubprocessFlags type class and check
if they are set. This has the benefit that we don't call needless functions
which walk the same table as well as avoiding mutating values to build
the error string.
https://bugzilla.gnome.org/show_bug.cgi?id=775913
When an invalid hostname is passed for connection, the
g_hostname_to_ascii() might fail when creating the request in
create_request(). Make sure that error is caught and reported rather
than passing "(null)" as the hostname of the site we want to connect to.
https://bugzilla.gnome.org/show_bug.cgi?id=772989
The tests defaultvalue, gdbus-peer and gdbus-unix-addresses will fail
without DBUS, so only run them in case we HAVE_DBUS_DAEMON.
Signed-off-by: Ingo Brückl <ib@wupperonline.de>
https://bugzilla.gnome.org/show_bug.cgi?id=767609
WSAWaitForMultipleEvents() only returns for one of the waiting threads, and
that one might not even be the one waiting for the condition that changed. As
such, only let a single thread wait on the event and use a GCond for all other
threads.
With this it is possible to e.g. have an UDP socket that is written to from
one thread and read from in another thread on Win32 too. On POSIX systems this
was working before already.
https://bugzilla.gnome.org/show_bug.cgi?id=762283
-2LL<<34 is undefined, because left-shifting a negative number is
undefined (it was implementation-defined behaviour in C99, but
is formally undefined in C11). The undefined behaviour sanitizer
picks this up.
Signed-off-by: Simon McVittie <smcv@debian.org>
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=775510
Reviewed-by: Colin Walters
glibc string.h declares memcpy() with attribute(nonnull(1,2)), causing
calls with NULL arguments to be treated as undefined behaviour.
This is consistent with ISO C99 and C11, which state that passing 0
to string functions as an array length does not remove the requirement
that the pointer to the array is a valid pointer.
gcc -fsanitize=undefined catches this while running OSTree's test suite.
Similarly, running the GLib test suite reports similar issues for
qsort(), memmove(), memcmp().
Signed-off-by: Simon McVittie <smcv@debian.org>
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=775510
Reviewed-by: Colin Walters
_g_dbus_auth_mechanism_server_data_send may fail in which case
we would endup getting a NULL data. In this case we should not
try to encode the data and simply let the state machine to continue.
The auth mechanism will change internally to REJECTED so we just
need to continue the iteration.
https://bugzilla.gnome.org/show_bug.cgi?id=775309
If we have an input parameter (or return value) we need to use (nullable).
However, if it is an (inout) or (out) parameter, (optional) is sufficient.
It looks like (nullable) could be used for everything according to the
Annotation documentation, but (optional) is more specific.
If g_socket_receive_message_with_timeout() is called with messages ==
NULL set the msg_control buffer to empty to not request the control
messages from recvmsg() at all.
This completely disables the control message processing and reduces
overhead, which might be critical at high packet rate.
https://bugzilla.gnome.org/show_bug.cgi?id=774520
This commit broke some tests, and I don't have the time
to fix up all the expected output, so I'll revert the changes
to the affected files for now.
This needs to be redone with the necessary test fixes.
I'm guessing the developments were done in 2.44 but the patches landed
after the 2.45.0 bump without an update to the Since tags.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=769630
GLib has g_unix_mount_at (mount_path) already, let's add g_unix_mount_for
(file_path) for whatever path. GLib already contains some private code
for such task. Let's make this code public. This functionality is needed
by GVfs (see Bug 771431) in order to avoid copy-and-pasting.
https://bugzilla.gnome.org/show_bug.cgi?id=772160
There have been some improvements to the tool recently, but it's hard to
know if those are available on a given system unless the tool provides a
--version commandline option.
https://bugzilla.gnome.org/show_bug.cgi?id=772269
It only works through its virtual methods, so while it could be
instantiated before (and this is technically an API break), any instance
of it would previously have crashed as soon as any of its methods were
called anyway.
If anybody has any problems with this ABI break, please make them known
during the 2.51 unstable development cycle and it can be reverted.
https://bugzilla.gnome.org/show_bug.cgi?id=772255
/proc/self/mountinfo is used to monitor changes of mounts with libmount.
However, GFileMonitor is used currently to monitor this file, which
doesn't work and consequently "changed" signal is never emitted. Special
monitoring needs to be used instead, same as it is used for /proc/mounts.
https://bugzilla.gnome.org/show_bug.cgi?id=662946
People might put more extraneous whitespace in a @since line in a
documentation comment, which should not affect the ordering of
methods/signals/etc. in the generated output.
https://bugzilla.gnome.org/show_bug.cgi?id=770372
Add --dependency-file=foo.d option to generate a gcc -M -MF style
dependency file for other build tools. The current output of
--generate-dependencies is only useful for use directly in Makefile
rules, but can't be used in other build systems like that.
The generated dependency file looks like this:
$ glib-compile-resources --sourcedir= test.gresource.xml --dependency-file=-
test.gresource.xml: test1.txt test2.txt test2.txt
test1.txt:
test2.txt:
test2.txt:
Unlike --generate-dependencies, the --dependency-file option can be
used together with other --generate options to create dependencies
as side-effect of generating sources.
Based on a patch by Tim-Philipp Müller in
https://bugzilla.gnome.org/show_bug.cgi?id=745754
The changes in this patch, compared to his are to always return
the hash table with file information from parse_resource_file, so
we can use it for dependency output, regardless if generate_dependencies
was TRUE or not.
Add --dependency-file=foo.d option to generate a gcc -M -MF style
dependency file for other build tools. The current output of
--generate-dependencies is only useful for use directly in Makefile
rules, but can't be used in other build systems like that.
The generated dependency file looks like this:
$ glib-compile-resources --sourcedir= test.gresource.xml --dependency-file=-
test.gresource.xml: test1.txt test2.txt test2.txt
test1.txt:
test2.txt:
test2.txt:
Unlike --generate-dependencies, the --dependency-file option can be
used together with other --generate options to create dependencies
as side-effect of generating sources.
Based on a patch by Tim-Philipp Müller.
https://bugzilla.gnome.org/show_bug.cgi?id=745754
Previously, this would not work, as it would result in comparing the
order of a string and an integer. Make it work, and make 'UNRELEASED'
compare higher than other versions so it's always treated as the latest
version.
'UNRELEASED' is commonly used by maintainers to highlight new API while
it's being prototyped, until they know which version it will actually
be released in. At the time of release, they replace all 'UNRELEASED'
strings in git with the new version number.
An example of this usage is here:
d380ac6a2a (9208ee267cb05db1afd3a5c323d71e51db489447_7619_7656)https://bugzilla.gnome.org/show_bug.cgi?id=769995
gcc 6 warns (fatally, by default) that %c only uses a 2-digit year
in some locales. The precise format does not seem to be important
for this sample code, so use ISO 8601 instead of suppressing the
warning with a pragma.
Signed-off-by: Simon McVittie <smcv@debian.org>
Reviewed-by: Colin Walters
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=768453
At some point, upstream SystemTap changed from using a
STAP_HAS_SEMAPHORES preprocessor variable for this, to using
_SDT_HAS_SEMAPHORES instead. We need to update our build system to
disable that as well.
The original discussion about use of semaphores is here:
https://bugzilla.gnome.org/show_bug.cgi?id=606044
This was breaking the build with -flto enabled, either because -flto
doesn’t work with semaphores.
https://bugzilla.gnome.org/show_bug.cgi?id=768198
GDatagramBased allows connection-oriented and connection-less sockets,
but does not allow stream-based sockets (because it’s datagram-based).
So it supports SCTP and UDP, but not TCP.
Clarify that in the documentation, and people sometimes confuse
connection-oriented with stream-based, due to the prevalence of TCP.
Use mnt_context_get_mtab instead of using mnt_context_get_table(), since
that's the recommended way of accessing mtab/mountinfo information, and
also because that way the (struct libmnt_table *) will get automatically
deallocated when calling mnt_free_context()
https://bugzilla.gnome.org/show_bug.cgi?id=769238
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
We use "tweaks" structures to track how a particular directory impacts
the list of added, removed and default applications. We maintain this
set of tweaks for each directory, in a hash table, keyed by unaliased
mime type name, in order to facilitate fast lookups.
A typo in the logic for creating and maintaining the uniqueness of these
structures was causing the default app to be selected incorrectly from
time to time. Fix that.
If a g_socket_client_connect_async() operation is cancelled between the
CONNECTING and CONNECTED events (i.e. while in the
g_socket_connection_connect_async() call), the code in
g_socket_client_connected_callback() would previously unconditionally
loop round and try the next socket address from the address enumerator
(by calling enumerator_next_async()). This would correctly handle the
cancellation and return from the overall task — but not before emitting
a spurious RESOLVING event.
Avoid emitting the spurious RESOLVING event by explicitly handling
cancellation at the beginning of g_socket_client_connected_callback().
https://bugzilla.gnome.org/show_bug.cgi?id=735179
This function adds a single main option entry to be handeled by
GApplication. The option entry has it arg_data field set to NULL
and will be added to the applications packed_options.
The rationale for this is that bindings will be able to add
command line options even when they can't use the un-boxed struct
GOptionEntry.
https://bugzilla.gnome.org/show_bug.cgi?id=727455
It turns out that this bug actually would (sometimes) impact any sort of
fixed-sized array with an alignment requirement of 8 due to incorrectly
counting the alignment inserted between the (aligned 4) array length and
the actual data.
Fix this properly and remove the exception for doubles.
https://bugzilla.gnome.org/show_bug.cgi?id=732754
We're using a precondition in the middle of the function, and if we
hit it, we leak the closure.
Let's allocate the closure per path; this allows us to allocate it
before path-specific preconditions, and better avoids a pointless
malloc/free pair in the unhandled case.
https://bugzilla.gnome.org/show_bug.cgi?id=733576
This is a best-effort approach to preventing SIGPIPE emissions on Darwin
and iOS, where they continue to be intercepted by the Xcode debugger
even if SIG_IGN prevents them crashing the program.
This is similar to the existing code which sets MSG_NOSIGNAL on all
send() calls. MSG_NOSIGNAL doesn't exist on Darwin though.
Based on a patch from Philip Withnall.
https://bugzilla.gnome.org/show_bug.cgi?id=728730
When establishing a D-Bus connection failed, g_dbus_object_manager_client_finalize()
calls g_object_ref(manager->priv->connection) when that pointer is NULL,
which is considered and logged as error by glib.
https://bugzilla.gnome.org/show_bug.cgi?id=732984
We don't use this for anything inside of GApplication yet, but Gtk is
about to start using it to find various bits of the application (such as
its menus, icons, etc.).
By default, we form the base path from the application ID to end up with
the familiar /org/example/app style.
https://bugzilla.gnome.org/show_bug.cgi?id=722092
This is not a functional change, as the hints field is static and hence
automatically initialised to zero — which happens to be what AF_UNSPEC
and the unspecified protocol are defined as. However, it’s best to be
explicit about this, in case AF_UNSPEC is _not_ defined as zero.
https://bugzilla.gnome.org/show_bug.cgi?id=732739
I recently needed to nul-terminate the returned buffer, and I wasn't
sure if g_input_stream_read() does that or not. I've checked
glocalfileinputstream.c, which calls read(2) which doesn't nul-terminate
the buffer. So I assume it's the same behavior for all GInputStream
subclasses.
https://bugzilla.gnome.org/show_bug.cgi?id=732704
When using this API, I wasn't sure what the cancellable does. I think
it's generally desirable to kill the subprocess if the wait operation is
cancelled, since in this case the application is no longer interested by
the subprocess.
https://bugzilla.gnome.org/show_bug.cgi?id=732704
A critical message is printed when a parameter of g_file_equal() is not
a GFile. When we read the documentation before this commit, we can think
that passing NULL or another type than GFile is allowed, but it is not
the case.
Another option is to allow NULL parameters. But for consistency with
e.g. g_str_equal(), it's probably better to keep the code as is.
https://bugzilla.gnome.org/show_bug.cgi?id=732357
- g_subprocess_launcher_spawn() and spawnv(): there is no other way
AFAIK to create a GSubprocess from a launcher. So these
functions are not "convenience helper".
- annotate optional arguments for g_shell_parse_argv().
- other trivial fix
https://bugzilla.gnome.org/show_bug.cgi?id=732357
Document that giving %NULL for the activate handler is supported since
GLib 2.40. We documented this on GSimpleAction itself (where the
default handler functionality is implemented) but expecting the user to
dig that up is asking a bit much.
Also, add some more explicit documentation about the conditions under
which each field is expected to be filled in.
https://bugzilla.gnome.org/show_bug.cgi?id=732429
This property has been deprecated for three years after only having
existed for one. We've wanted to reuse the name for all that time, so
let's try to actually remove it now and see if we can get away with it.
https://bugzilla.gnome.org/show_bug.cgi?id=732102
Instead of closing the sockets explicitly, let them close themselves
when their final reference is dropped. This makes use of
g_socket_listener_add_socket() more natural.
https://bugzilla.gnome.org/show_bug.cgi?id=732107
This is quite important, as it means you can safely let the GSocket drop
out of scope while maintaining a reference to the GSource, and the
socket will remain open. That means fewer closure structures, simpler
code, and fewer allocations.
https://bugzilla.gnome.org/show_bug.cgi?id=732081
'folder' is the name of the folder icon in the incon naming spec,
and the Adwaita icon theme doesn't include an inode-directory icon.
This fixes folders appearing as generic file in the file chooser.
https://bugzilla.gnome.org/show_bug.cgi?id=731996
The stdout FD passed to dbus-daemon is propagated to all its child
processes, such as service activated processes. If we close the FD after
reading the bus address from the daemon, any child process which
subsequently writes to stdout (e.g. for logging) will get a SIGPIPE and
explode.
Instead of closing the stdout FD immediately after dbus-daemon has
spawned, keep it open until the daemon is killed.
https://bugzilla.gnome.org/show_bug.cgi?id=732019
Availability of the g_nextstep_settings_backend_get_type() prototype
is controlled by HAVE_COCOA in gsettingsbackendinternal.h and the
actual implemenation by OS_COCOA in Makefile.am. Therefore, the
giomodule.c call to that function should also be protected by a COCOA
token rather than an CARBON token (cocoa and carbon are independent
autoconf tests).
https://bugzilla.gnome.org/show_bug.cgi?id=731425
GResolver doesn't do full validation of its inputs, so in some of
these tests, the fact that we were getting back
G_RESOLVER_ERROR_NOT_FOUND is because the junk string was getting
passed to an upstream DNS resolver, which returned NXDOMAIN. But if
there's no network on the machine then we'd get
G_RESOLVER_ERROR_INTERNAL instead in that case.
Windows does not like g_unlink() to be called on files whose file
descriptor is still open, so doing that would cause a permission
denied error. Since the fd is not used in that function after
acquiring the temp file, close it earlier before
g_file_set_contents(), so that it can complete successfully.
This fixes a number of GTK+ tests on Windows.
https://bugzilla.gnome.org/show_bug.cgi?id=719344
- GSubprocessLauncher exists since 2.40, not 2.36
- more logical order for g_markup functions
- fix short description of GMarkup
- GMarkupParser: specify that some parameters are NULL-terminated.
- g_string_new (NULL); is possible.
- other trivial fixes.
https://bugzilla.gnome.org/show_bug.cgi?id=728983
* removed passing GError to ensure_input_padding() function
- it was necessary before commit 3e5214c15c
when we used GData*Streams and GMemoryInputStream with
g_seekable_seek() - now it's useless,
* removed checking return value of ensure_input_padding()
function - in previous implementation (like above)
g_seekable_seek() could return FALSE - now it's always TRUE,
* removed passing GError to g_memory_buffer_read_*() functions
and checking returned value - it also has been inherited after
old implementation with g_data_input_stream_read_*() functions
- now it's also useless
* cleaned up code formatting,
https://bugzilla.gnome.org/show_bug.cgi?id=729875
Expand the functionality of g_desktop_app_info_set_desktop_env() to
include the possibility of passing strings containing ':' characters (as
some apps, such as gnome-session, are directly passing the value of
XDG_CURRENT_DESKTOP). At the same time, deprecate it, since now we get
the list from the environment variable for ourselves.
Modify the checks in g_desktop_app_info_get_show_in() to deal with
multiple items listed in XDG_CURRENT_DESKTOP. For example, if we find
that we have
XDG_CURRENT_DESKTOP=GNOME-Classic:GNOME
and a desktop file contains:
OnlyShowIn=GNOME
then we will show this file because of the fallback to GNOME. If the
file _also_ contains the line:
NotShowIn=GNOME-Classic
Then we will not show it, because GNOME-Classic comes before GNOME in
XDG_CURRENT_DESKTOP.
https://bugzilla.gnome.org/show_bug.cgi?id=729813
GDummyTlsConnection didn't implement the "interaction" property,
meaning you'd get warnings if you tried to set it while creating a
GTlsConnection when using the dummy backend. (Of course, trying to
create the GTlsConnection will fail anyway, but it ought to fail
without hitting any g_warnings.)
It was previously possible for GThreadedResolver to return an empty list
and no error in response to a g_resolver_lookup_by_name() call, if it
happened that all the addresses returned by getaddrinfo() could not be
converted from native addresses to GSocketAddresses.
Fix that by setting a G_RESOLVER_ERROR_NOT_FOUND if the returned list is
empty.
https://bugzilla.gnome.org/show_bug.cgi?id=728776
The documentation previously wasn’t clear about whether the GResolver
methods could return an empty list and no error. On balance, this seems
like a bad idea, and GResolver should commit to always return a
non-empty list, or an error (which should be G_RESOLVER_ERROR_NOT_FOUND
if the list would otherwise be empty).
https://bugzilla.gnome.org/show_bug.cgi?id=728776
ddf82a25 removed the use of non-literal format strings from
gthreadedresolver.c, but left the "#pragma GCC diagnostic ignored
-Wformat-nonliteral" behind.
These did show up in the html. Since symbol names are checked for a
trailing plural s when generating the docs, the links stay functional
after removing these comments.
https://bugzilla.gnome.org/show_bug.cgi?id=728380
Redo the code for type-based selection of applications (all,
recommended, default, fallback) based on the new DesktopFileDir
structures that we introduced last cycle.
At the same time, we expand the functionality to add support for the new
features of the specification:
- moving ~/.local/share/applications/mimeapps.list to ~/.config/
- per-desktop default applications (via XDG_CURRENT_DESKTOP)
- sysadmin customisation of defaults (via /etc/xdg/mimeapps.list)
- deprecation of the old defaults.list, favouring the use of
/usr/share/applications/mimeapps.list (or gnome-mimeapps.list) to
accomplish the same
We modify the mimeapps testcase to check for mimeapps.list having been
created in XDG_CONFIG_HOME instead of XDG_DATA_HOME.
The modification is a net reduction of code (due to less duplication in
bookkeeping). It is also an increase in performance and reduction in
memory consumption (due to simplified data structures). Finally, it
removes the stat-based timestamp checking in favour of the
GFileMonitor-based approach that was already being used in the
implementation of DesktopFileDir (in order to know if we had to rescan
the desktop files themselves).
https://bugzilla.gnome.org/show_bug.cgi?id=728040
We currently assume that setting an application as the default will take
it to the front of the list of supported applications for a given type,
but this is not necessarily true.
Check instead that the application is actually set as default.
https://bugzilla.gnome.org/show_bug.cgi?id=728040
Set XDG_DATA_DIRS to make sure we don't use /usr/share from the
appmonitor test. We will soon throw a warning if we find defaults.list,
so make sure we don't open ourselves up to that if there is one on the
system.
https://bugzilla.gnome.org/show_bug.cgi?id=728040
The desktop file for myapp3 didn't declare support for image/png, but
the testcase expects it to be recommended on the basis of it being the
default app according to defaults.list.
This will not work in the future -- we will only list apps that actually
support the filetype in question, unless they've been explicitly added
as associations.
https://bugzilla.gnome.org/show_bug.cgi?id=728040
The app launch context may just not support startup notification,
in which case, g_app_launch_context_get_startup_notify_id() will
return NULL.
Failure to take this into account leads to criticals like this:
gnome-session[8489]: GLib-CRITICAL: g_variant_new_take_string: assertion 'string != NULL' failed
gnome-session[8489]: GLib-CRITICAL: g_variant_new_variant: assertion 'value != NULL' failed
gnome-session[8489]: GLib-CRITICAL: g_variant_get_type: assertion 'value != NULL' failed
gnome-session[8489]: GLib-CRITICAL: g_variant_type_is_subtype_of: assertion 'g_variant_type_check (type)' failed
https://bugzilla.gnome.org/show_bug.cgi?id=728066
Add G_DBUS_ERROR codes for:
* org.freedesktop.DBus.Error.UnknownObject
* org.freedesktop.DBus.Error.UnknownInterface
* org.freedesktop.DBus.Error.UnknownProperty
* org.freedesktop.DBus.Error.PropertyReadOnly
These were discussed on the dbus mailing list
and introduced in the following libdbus commit:
2c34514620c4b79ea4ec71d1db583379138d01ac
https://bugzilla.gnome.org/show_bug.cgi?id=727900
g_tls_certificate_list_new_from_file() was supposed to ignore non-PEM
content, but it accidentally required that there not be anything after
the last certificate. Fix that.
https://bugzilla.gnome.org/show_bug.cgi?id=727692
Make sure that the @ sign is inside the authority part before attempting
to parse the userinfo. We do this by checking if the @ sign comes before
any of the possible authority delimiters.
Add unit test to verify parsing of ftp://ftp.gnome.org/start?foo=bar@baz
https://bugzilla.gnome.org/show_bug.cgi?id=726040
Rather than having special code in gsocket.c, handle Winsock errors
along with other Win32 errors in gioerror.c
Also, reference g_win32_error_message() from the
g_io_error_from_win32_error() docs, and update the
g_win32_error_message() docs to clarify that it works with Winsock
error codes too.
Map EPROTONOSUPPORT, ESOCKTNOSUPPORT, EPFNOSUPPORT and EAFNOSUPPORT to
G_IO_ERROR_NOT_SUPPORTED in g_io_error_from_errno(). (GSocket's
socket_io_error_from_errno() already did this with the corresponding
Winsock errors.)
Also map EOPNOTSUPP, which on Linux is the same as ENOTSUP, but may
not be on other platforms.
Also, rewrite the EAGAIN/EWOULDBLOCK section to use the simpler idiom
used by EEXIST/ENOTEMPTY and (now) ENOTSUP/EOPNOTSUPP.
Use #GVariant instead of GVariant.
g_notification_add_button_with_target,
g_notification_set_default_action_and_target:
Replace 'format_string' with 'target_format'.
g_notification_set_default_action_and_target_value:
Remove paragraph that apparently had been accidentally copied from
g_notification_set_default_action_and_target.
https://bugzilla.gnome.org/show_bug.cgi?id=727123
In the event that a GSettings object is being destroyed just as a change
signal is being delivered, the destroying thread will race with the
dconf worker thread for acquiring the lock on the GSettingsBackend.
If the signalling thread gets there first then the destroying thread
will block on the lock. The signalling thread adds a reference to the
GSettings object that is being destroyed and releases the lock. The
idea is that this should prevent the GSettings object from being
destroyed and thus maintain its entry in the list. Unfortunately, the
weak reference notify function is already running and as soon as we
release the lock, the list entry is removed.
The signalling thread crashes.
This bug is indicative of a serious problem encountered in many
situations where GObject instances are touched from multiple threads.
Ideally, we will move to a place where g_object_ref() is not called at
all on the GSettings object from the dconf worker thread and instead, a
dispatch will be done without holding a reference (similar to how
GAppInfoMonitor presently works). This would also prevent the
unfortunate case of someone dropping what they assume to be the last
reference on a GSettings object, only to have an already-pending signal
delivered once they return to the mainloop, crashing their program.
Making this change for GSettings (with multiple instances per thread,
the possibility of multiple backends and each instance being interested
in different events) is going to be extremely non-trivial, so it's not a
change that makes sense at this point in the cycle.
For now, we can do a relatively small and isolated tweak so that we
never access the list except under a lock. We still perform the bad
pattern of acquiring a ref in a foreign thread which means that we still
risk delivering a signal to a GSettings object that the user has assumed
is dead (unless they explicitly disconnect their signal handler). This
is a problem that we already had, however.
https://bugzilla.gnome.org/show_bug.cgi?id=710367
Change the order of the arguments on the (internal) keys_changed callback in
GSettingsListenerVTable.
This means that all functions in the table now fit the following signature:
void (* f) (GObject *target,
GSettingsBackend *backend,
const gchar *name_or_path,
gpointer origin_tag,
const gchar * const *names);
allowing the possibility of arguments ignored at the end.
This allows us to simplify our dispatch-to-thread code in GSettingsBackend,
making it a bit less generic.
So far, this should be a straight refactor.
https://bugzilla.gnome.org/show_bug.cgi?id=710367
The _finish functions for GUnixVolume _mount and _eject functions were
never implemented, having been simply stubbed out as 'return TRUE;'.
Implement them.
https://bugzilla.gnome.org/show_bug.cgi?id=724916
The existing code is buggy and now that we have GSubprocess, we should just use
it instead, allowing for some substantial reduction in complexity.
https://bugzilla.gnome.org/show_bug.cgi?id=724916
As of e6af432, g_content_type_get_symbolic_icon() returns non-symbolic
fallbacks. Thus, we can't append another symbolic icon to the fallbacks.
The special case was a bit of a hack anyway. It was only applied to
themed icons and there was no generic fallback for mime types that are
not folders.
https://bugzilla.gnome.org/show_bug.cgi?id=726046
We need to have these in BUILT_SOURCES so that 'make' knows to generate them
before attempting to compile other .c files in the same directory (since some
of these files include the header).
Should fix up remaining issues about partial versions of this file being
included under parallel builds.
https://bugzilla.gnome.org/show_bug.cgi?id=725891
Add a test for GSubprocess to test setting, unsetting and inheritance of
environment variables. Use communicate() to give it a bit more of a
workout as well.
https://bugzilla.gnome.org/show_bug.cgi?id=725651
On the splice for stdout or stderr completing, GSubprocess calls
_slice_finish() to collect the result.
We assume that a zero return value here means failure, but in fact this
function returns a gssize -- the number of bytes transferred, or -1 for
an error.
This causes GSubprocess to mistakenly think that it has an error when it
actually just has an empty buffer (as would be the case when collecting
stderr from a successful command).
Check for -1 instead of FALSE to detect the error.
https://bugzilla.gnome.org/show_bug.cgi?id=724916
Add the basename from the first component of the Exec line to the list of
strings to search for via g_desktop_app_info_search().
We treat Exec as a fairly strong match -- just below the visible name.
Add a testcase to make sure everything is working OK.
https://bugzilla.gnome.org/show_bug.cgi?id=725023
Visual C++ is quite zealous about checking against the types used in the
initializing of array of structures, even up to Visual C++ 2013. Fix this
by splitting up the initializing steps.
https://bugzilla.gnome.org/show_bug.cgi?id=724609
There is no longer any code left in the check/prepare functions on UNIX,
so put %NULL in the GSourceFuncs vtable.
This also allows us to simplify some logic.
https://bugzilla.gnome.org/show_bug.cgi?id=724707
We are reusing the GPollFD.revents field of the source to store a
temporary value. Use a local variable for that instead.
This is a refactor to make the next commit easier to understand.
https://bugzilla.gnome.org/show_bug.cgi?id=724707
Now that GCancellable's GSource is based on _set_ready_time() instead of
an fd, we should use it as a child source, instead of forcing the
creation of the fd and adding it as a poll.
https://bugzilla.gnome.org/show_bug.cgi?id=724707
Windows does not come with inet_aton(), and this check on IPv4 addresses
is actually not needed on Windows as the getaddrinfo() implementation on
Windows already rejects non-standard and non-real IPv4 numbers-and-dots
addresses.
https://bugzilla.gnome.org/show_bug.cgi?id=724609
After getting an EINTR, g_socket_condition_timed_wait() has to adjust
its timeout, but it was trying to convert from nanoseconds to
microseconds by multiplying by 1000 rather than dividing... Oops.
https://bugzilla.gnome.org/show_bug.cgi?id=724239
There is a race condition in the makefile that can result in build failures like this in parallel builds:
| ./gdbus-test-codegen-generated.h:7:0: error: unterminated #ifndef
| #ifndef __GDBUS_TEST_CODEGEN_GENERATED_H__
This is because a rule like this:
x.c x.h: prerequisites
@commands
doesn't consider x.c and x.h together. Instead, it expands to two rules, one to
generate x.c and one to generate x.h, which happen to run the same commands. In
the worst case they execute in parallel, overwriting each other's output.
Signed-off-by: Ross Burton <ross.burton@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=723616
If a GSimpleAsyncResult has a NULL source tag, allow it to compare
valid to a non-NULL source tag in g_simple_async_result_is_valid(), to
simplify cases where, eg, g_simple_async_result_new() and
g_simple_async_result_report_error_in_idle() are both used.
https://bugzilla.gnome.org/show_bug.cgi?id=721458
We have a configure.ac check for lib.exe that attempts to enable
creation of .lib files for our 5 public libraries. That has been broken
for a long time for two reasons:
1) the Makefiles hardcode 'lib' instead of 'lib.exe'
2) we dropped generation of .def files quite some time ago (except for
in gthread where we have the two-symbol file under version control)
Add new rules for creating .def files from dumpbin.exe (which you should
have if you have lib.exe) and fix the .lib rules to use lib.exe.
Add a bit of $(AM_V_GEN) all around, as well.
https://bugzilla.gnome.org/show_bug.cgi?id=722033
In addition to the standard "192.168.1.1" format, there are numerous
legacy IPv4 address formats (such as "192.168.257",
"0xc0.0xa8.0x01.0x01", "0300.0250.0001.0001", "3232235777", and
"0xc0a80101"). However, none of these forms are ever used any more
except in phishing attempts. GLib wasn't supposed to be accepting
these addresses (neither g_hostname_is_ip_address() nor
g_inet_address_new_from_string() recognizes them), but getaddrinfo()
accepts them, and so the parts of gio that use getaddrinfo()
accidentally did accept those formats.
Fix GNetworkAddress and GResolver to reject these address formats.
https://bugzilla.gnome.org/show_bug.cgi?id=679957
Windows needs a special inefficient hack to implement
g_socket_get_available() correctly for UDP sockets, but that hack
isn't needed for TCP, and in fact, might give the wrong answer in that
case. Fix it to only use the hack with UDP.
Also, fix that case to handle non-blocking sockets as well.
And add a test case for g_socket_get_available() with TCP.
https://bugzilla.gnome.org/show_bug.cgi?id=723422
Since we are no longer using sgml mode, using /* */ to
escape block comments inside examples does not work anymore.
Switch to using line comments with //
Our check for inotify_init1() being defined is broken. We happily
declare that inotify is supported, even if the check fails.
This was originally intended to check for inotify_init1 in the libc so
that we could fall back to inotify_init if it was not yet defined.
FreeBSD has a libinotify that emulates the inotify API via kqueue. It
installs a <sys/inotify.h> header and requires linking to -linotify. We
don't want to falsely detect working inotify in this case.
Treat the lack of inotify_init1() in the libc as a lack of inotify
support. This requires only a new libc -- we still support old kernels:
in the case that inotify1_init() fails, we fall back to inotify_init().
https://bugzilla.gnome.org/show_bug.cgi?id=724330
It’s not enough to close a connection by calling g_input_stream_close()
and g_output_stream_close() on its two substreams: to close the
underlying socket, one must use g_io_stream_close(). Document that.
https://bugzilla.gnome.org/show_bug.cgi?id=724278
Since all element markup is now gone from the doc comments,
we can turn off the gtk-doc sgml mode, which means that from
now on, docbook markup is no longer allowed in doc comments.
To make this possible, we have to replace all remaining
entities in doc comments by their replacement text, & -> &
and so on.
Add support for parsing command line options with GApplication.
You can add GOptionGroup and GOptionEntry using two new APIs:
g_application_add_option_group() and
g_application_add_main_option_entries().
Also add a "handle-local-options" signal that allows handling of
commandline arguments in the local process without having to override
local_command_line.
As a special feature, you can have a %NULL @arg_data in a GOptionEntry
which will cause the argument to be stored in a GVariantDict. This
dictionary is available for inspection and modification by the
"handle-local-options" signal and can be forwarded to the primary
instance in cases of command line invocation (where it can be fetched
using g_application_command_line_get_options()).
https://bugzilla.gnome.org/show_bug.cgi?id=721977
In some virtualization setups, ifindexes can end up becoming very
large, and so the existing code that assumes that *some* interface
must have an index less than 255 fails.
Fix this by explicitly looking for "lo" first. And then if that fails
(on Windows, or other systems where the loopback interface is not
called "lo"), try indexes up to 1024 rather than 255.
https://bugzilla.gnome.org/show_bug.cgi?id=723048
For some reason, IPv6 link-local multicast routing changes all the
time. GNetworkMonitorBase was already ignoring them for purposes of
emitting network-changed, but GNetworkMonitorNetlink would still
trigger a re-dump after getting one, so network-changed would end up
getting emitted anyway.
glocalfile.c: In function 'g_local_file_measure_size_of_file':
glocalfile.c:2654:3: warning: passing argument 2 of 'g_lstat' from
incompatible pointer type [enabled by default]
if (g_lstat (name->data, &buf) != 0)
^
In file included from glocalfile.c:68:0:
../glib/gstdio.h:135:5: note: expected 'struct GStatBuf *' but argument
is of type 'struct _stati64 *'
https://bugzilla.gnome.org/show_bug.cgi?id=711547
gdbusauthmechanismexternal.c: In function 'mechanism_client_initiate':
gdbusauthmechanismexternal.c:355:3: warning: 'initial_response' may be
used uninitialized in this function [-Wmaybe-uninitialized]
return initial_response;
^
gdbusauthmechanismexternal.c:332:10: note: 'initial_response' was
declared here
https://bugzilla.gnome.org/show_bug.cgi?id=711547
glocalfileinfo.c: In function '_g_local_file_info_get':
glocalfileinfo.c:1955:11: warning: passing argument 3 of
'get_thumbnail_attributes' from incompatible pointer type [enabled by
default]
get_thumbnail_attributes (path, info, &statbuf);
^
glocalfileinfo.c:1285:1: note: expected 'const struct GStatBuf *' but
argument is of type 'struct _stati64 *'
get_thumbnail_attributes (const char *path,
https://bugzilla.gnome.org/show_bug.cgi?id=711547
If the action is stateful and the user doesn't have their own activate handler
then do some reasonable things for ourselves.
After a lot of experience using stateful GSimpleAction it turns out that
people almost always end up using it in the same ways:
A boolean-typed stateful action with no parameter is most likely going
to want to be toggled. Any other type of action that has the parameter
type equal to the state type probably intends for activation to
represent a request to change the state.
This patch implements those two cases. This will let people stop
writing their own trivial handlers over and over.
https://bugzilla.gnome.org/show_bug.cgi?id=722503
Clarify in the documentation that the commandline arguments passed
around by GApplication (to local_command_line and returned via
g_application_command_line_get_arguments()) are in the GLib filename
encoding (ie: UTF-8) on Windows, not the system code page.
Fix the mismatch that would result from having argv passed to
g_application_run() in main() on Windows (where it is in the system
code page) by ignoring argc/argv on Windows and calling
g_win32_get_command_line() for ourselves. Document this.
This might be a slight API break on Windows: we documented that it was
possible to call g_application_run() with arguments other than argc/argv
and now doing that will result in those arguments being ignored. It has
always been recommended practice to only call g_application_run() from
main() directly, however, and all of our code examples have shown only
this. We will see if this causes any issues and consider reevaluating
the situation if so.
https://bugzilla.gnome.org/show_bug.cgi?id=722025
Add a note to the documentation for g_file_new_for_commandline_arg()
that this function is intended to operate on strings already in the GLib
filename encoding on Windows.
This has been the case for a long time, but this documents the
requirement.
https://bugzilla.gnome.org/show_bug.cgi?id=722025
g_strconcat() allocates memory, it needs to be freed.
==10653== 1,400 bytes in 50 blocks are definitely lost in loss record
1,838 of 1,851
==10653== at 0x4A0645D: malloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==10653== by 0x54ACB22: g_malloc (gmem.c:102)
==10653== by 0x54ACE4D: g_malloc_n (gmem.c:343)
==10653== by 0x54C8463: g_strconcat (gstrfuncs.c:589)
==10653== by 0x4D6ED38: get_xattrs_from_fd (glocalfileinfo.c:660)
==10653== by 0x4D71622:
_g_local_file_info_get_from_fd (glocalfileinfo.c:2028)
==10653== by 0x4D731A0:
g_local_file_input_stream_query_info (glocalfileinputstream.c:356)
==10653== by 0x4C996D8:
g_file_input_stream_query_info (gfileinputstream.c:148)
==10653== by 0x4C863F6: file_copy_fallback (gfile.c:3120)
==10653== by 0x4C86DD2: g_file_copy (gfile.c:3398)
https://bugzilla.gnome.org/show_bug.cgi?id=722357
The default local_command_line handler has a fast return path for the
case that we handle the commandline by forwarding it to the primary
instance, but this doesn't account for the fact that we may want to
become a service.
Allow for this by making sure we don't take the fast path of the service
flag is set.
Add a --gapplication-service switch to the default implementation of
local_command_line. This name is unlikely to clash with any option used
by an existing application.
When a normal application (neither service nor launcher) is launched with
exactly this one argument, G_APPLICATION_IS_SERVICE will be set.
The idea is that people will write their D-Bus service file with
--gapplication-service on the Exec line. This provides a nice
compromise for people who want the benefits of DBusActivatable
applications but without losing the ability to easily run them directly
(under the debugger or inside jhbuild, etc.)
https://bugzilla.gnome.org/show_bug.cgi?id=710965
Make sure we escape any special characters that are found in annotation
names or values to avoid emitting a malformed XML document in response
to an Introspect call.
https://bugzilla.gnome.org/show_bug.cgi?id=721796
The file extension of the GIO module could be something other than .so,
depending on platform. Use G_MODULE_SUFFIX so that the test will run
correctly on non-*nix platforms, such as Windows.
https://bugzilla.gnome.org/show_bug.cgi?id=719344
If installed tests are not enabled, installed_testdir is not
defined, so we end up trying to create /modules and to chmod
things in /x-content/, which is not right.
When losing the D-Bus connection, we would write to stdout about it just
before killing ourselves with SIGTERM. We're a library, so we should
probably use stderr instead.
https://bugzilla.gnome.org/show_bug.cgi?id=721324
Part of the purpose of g_settings_get_child() was that it could be used
after you delay() a GSettings object, and then apply() all of the
settings together. In order for that to work, we need to share the
backend.
https://bugzilla.gnome.org/show_bug.cgi?id=720891
The x-content/win32-software type is only recognized if
the autorun.exe file is executable. Since the file is installed
as data, we need to fix up its permissions in an
install-data-hook.
This test is inspired by its namesake in GTK+. We instantiate
all types, and check the default values of their properties,
with some exceptions for types that are known not to work.
In case an object is already monitored, we lock then return without
unlocking it which can then result in a self deadlock. So properly
unlock before returning.
https://bugzilla.gnome.org/show_bug.cgi?id=721074
Use g_variant_parse_error_print_context() to format the error message
from the GVariant parser.
There is a slightly dubious interaction with the "parse me harder"
functionality here. We're probably going to have to deal with that
separately.
https://bugzilla.gnome.org/show_bug.cgi?id=715028
I recently had to track down why these tests failed. Turned
out that some rogue package on my system had installed mime
types that declared all files with 3 letter names to be
'chemical/x-turbomole-vibrational'.
This change will make it more obvious what is going on by
mentioning the mime types in the assertion message.
When replacing a version of goa-daemon (from gnome-online-accounts)
by a newer version with some added interfaces, evolution-data-server
and the gvfs-goa volume monitor might crash as there's no interface
definition for this new interface.
Work-around this by returning earlier from the _notify() implementation,
rather than accessing invalid memory.
https://bugzilla.gnome.org/show_bug.cgi?id=720539
Add missing (allow-none) annotations to
g_desktop_app_info_launch_uris_as_manager(). Tested with
python -c "from gi.repository import GLib, Gio; Gio.DesktopAppInfo.new('gcalctool.desktop').launch_uris_as_manager([], None, GLib.SpawnFlags.SEARCH_PATH|GLib.SpawnFlags.STDOUT_TO_DEV_NULL, None, None, None, None)"
which is necessary to do a launch_uris() without leaking stdout.
https://launchpad.net/bugs/1259721
GDBusConnection cleanup is inherently racy due to its use of worker
threads. Put tests that expect a NULL G_BUS_TYPE_SESSION singleton
as the first tests to work around cleanup races.
https://bugzilla.gnome.org/show_bug.cgi?id=719837
Allow only format strings that copy all values (i.e, don't contain '&'),
as the returned pointers might become invalid in some rare cases.
Since this is technically an API break, this patch only prints a
critical when a faulty format string is detected, but still fetches the
values.
https://bugzilla.gnome.org/show_bug.cgi?id=719979
Usually async methods copy/ref its arguments so caller can
forget about them. g_file_replace_contents_async() and
g_output_stream_write_async() are exceptions.
https://bugzilla.gnome.org/show_bug.cgi?id=690525
The desktop-files directory contains a mimeapps.cache file
that was not installed as data for installed tests, causing
the file measure test to fail only in when installed.
Make the testcase compare the byte size to what is reported
by du. Also add a test for the async api, and mak eit test
the progress reporting callback.
Comparing the code generated for the setter and other methods without
(real) return value, I noticed that the setter does not unref the
gvariant it gets.
https://bugzilla.gnome.org/show_bug.cgi?id=719472
This function turns a varargs argument list into a string array,
but forgets to NULL-terminate it. This function was not covered
by unit tests...so it was broken.
The test reveals that there's something fishy with this monitor.
One has to call g_app_info_get_all() for it to start working,
and then it only works once.
The previous patch to simplify the GSettings commandline tool by making
more use of global variables went a bit too far and broke 'gsettings
monitor' when used without a specific key.
Fix that up again.
The static analyser (correctly) considers a type check to fail if the
variable is NULL. In this case, the address must be non-NULL as no error
was thrown by g_socket_connection_get_remote_address(), but the static
analyser doesn’t know this.
Add a non-NULL assertion anyway, both to shut the analyser up, and
because it’s good extra testing.
Found by scan-build.
https://bugzilla.gnome.org/show_bug.cgi?id=113075
These prevent some false positives from the static analyser which are
caused by it not inspecting the invariants of
g_subprocess_communicate[_utf8]_finish() (i.e. that stdout and
stdout_str will always be set unless an error was returned).
They’re also good testing anyway.
Found by scan-build.
https://bugzilla.gnome.org/show_bug.cgi?id=113075
If the initial part of the header (‘MIME-TreeMagic’) is valid, but the
following line does not start with ‘[’ (i.e. is not a valid section
line), insert_matchlet() will be called with a NULL match pointer, and
will crash with a NULL pointer dereference.
Fix this by bailing out if a valid section line isn’t encountered before
the first insert_matchlet() call (i.e. between the header line and the
first data line).
Note that this has not been tested against a real treemagic file; the
fix is purely theoretical.
Found by scan-build.
https://bugzilla.gnome.org/show_bug.cgi?id=113075
In the case that (n_fds == 0 && fds == NULL), memcpy() would be called
against a NULL src pointer. Even though the number of bytes to copy is
0, avoid the possibility of a crash by only calling if fds is non-NULL.
Found by scan-build.
https://bugzilla.gnome.org/show_bug.cgi?id=113075
The static analyser will check dynamic type assertions and assume that
if they fail, the variable can either have the wrong type, or be NULL
(which is correct). The analyser doesn’t know that other constraints in
the API ensure the variable is non-NULL.
Add a non-null assertion to help the static analyser and shut it up in
this case.
https://bugzilla.gnome.org/show_bug.cgi?id=113075
This can happen if the hash table lookup for ‘noncefile’ fails, and
hence the first ‘goto out’ is hit, at which point resolver is still
NULL.
Found with scan-build.
https://bugzilla.gnome.org/show_bug.cgi?id=113075
Be a little bit more careful in regards to initializing a primitive type
variable before passing it by reference, as it could have random stuff
in the variable's address depending on the CRT, such as MSVCR110.DLL,
causing random, invalid stuff being written in that address.
This will fix this test when built with Visual Studio 2012.
https://bugzilla.gnome.org/show_bug.cgi?id=711047
G_OS #ifdefs are only available once glibconfig.h has been
evaluated ; that is, after including glib headers.
Move this block down so it gets correctly evaluated.
Make it possible to skip the terminal-launching test simply
by setting DISPLAY= . Previously, you had to unset DISPLAY,
which is a little more cumbersome.
https://bugzilla.gnome.org/show_bug.cgi?id=711178
One testcase was launching appinfo-test from a GAppInfo that
does not have a filename. In this case, the G_LAUNCHED_DESKTOP_FILE
envvar is not exported. Make appinfo-test deal with that, without
spewing warnings.
https://bugzilla.gnome.org/show_bug.cgi?id=711178
The actions test tests the GSimpleActionGroup API. Maybe this
should be moved to use GActionMap, but for now, just disable
the deprecations.
There was also one test that wasn't actually hooked up, so
do that as well.
Most _list_schemas() uses were to check for the availability
of a particular schema. g_settings_schema_source_lookup() is
a better way to do this.
https://bugzilla.gnome.org/show_bug.cgi?id=712315
In Windows development environments that have it, <unistd.h> is mostly
just a wrapper around several other native headers (in particular,
<io.h>, which contains read(), close(), etc, and <process.h>, which
contains getpid()). But given that some Windows dev environments don't
have <unistd.h>, everything that uses those functions on Windows
already needed to include the correct Windows header as well, and so
there is never any point to including <unistd.h> on Windows.
Also, remove some <unistd.h> includes (and a few others) that were
unnecessary even on unix.
https://bugzilla.gnome.org/show_bug.cgi?id=710519
Assume unix platforms support the original POSIX.1 standard.
Specifically, assume that if G_OS_UNIX, then we have chown(),
getcwd(), getgrgid(), getpwuid(), link(), <grp.h>, <pwd.h>,
<sys/types.h>, <sys/uio.h>, <sys/wait.h>, and <unistd.h>.
Additionally, since all versions of Windows that we care about also
have <sys/types.h>, we can remove HAVE_SYS_TYPES_H checks everywhere.
Also remove one include of <sys/times.h>, and the corresponding
configure check, since the include is not currently needed (and may
always have just been a typo for <sys/time.h>).
https://bugzilla.gnome.org/show_bug.cgi?id=710519
Assume all supported platforms implement C90, and therefore they
(correctly) implement atexit(), memmove(), setlocale(), strerror(),
and vprintf(), and have <float.h> and <limits.h>.
(Also remove the configure check testing that "do ... while (0)" works
correctly; the non-do/while-based version of G_STMT_START and
G_STMT_END was removed years ago, but the check remained. Also, remove
some checks that configure.ac claimed were needed for libcharset, but
aren't actually used.)
Note that removing the g_memmove() function is not an ABI break even
on systems where g_memmove() was previously not a macro, because it
was never marked GLIB_AVAILABLE_IN_ALL or listed in glib.symbols, so
it would have been glib-internal since 2004.
https://bugzilla.gnome.org/show_bug.cgi?id=710519
My application (hotssh) would like to get the resolved address from DNS,
before we start the connect().
We could add a new event, but it's easy enough to just cache it on the
GSocketConnection; this avoids any new API.
https://bugzilla.gnome.org/show_bug.cgi?id=712547
It makes sense to match on GenericName in case an application does
not provide any keywords, but the Keywords field has been added
to explicitly support the search case, while GenericName was used
to be displayed in menus, so it makes more sense to consider
Keywords more (or equally) relevant for search.
https://bugzilla.gnome.org/show_bug.cgi?id=711640
Just copy the schemas to the builddir and compile them in place instead
of trying to mess around with creating the compiled file in a different
dir. This solves issues in the summary/description testcase when
GSettings expects the usual situation of having the .xml files present
in the same directory.
We need to check for the correct line endings on Windows (\r\n) for the
echo tests and currently need to skip the test_echo_eof test there, as
it depends on the cat utility that is not normally found on Windows, and
using an external installation of cat via MSYS or Cygwin would render the
test program to hang as cat waits for user input.
https://bugzilla.gnome.org/show_bug.cgi?id=711047
Various tests were depending on local_error being set by a callback
when it could never have been the case. Simplify async error detection
logic in those cases, and fix leak of GError.
https://bugzilla.gnome.org/show_bug.cgi?id=711802
We had a GApplication testcase that handled both open and commandline.
This only way that this worked was by implementing the commandline
handler without actually setting the HANDLES_COMMAND_LINE flag.
This behaviour is now invalid, so just rip out the offending part of the
test.
https://bugzilla.gnome.org/show_bug.cgi?id=711099
The first time this function is called we load all of the keyfiles in
the directory, ignoring the 'Hidden' ones and build an index out of the
interesting fields using g_str_tokenize_and_fold().
We do prefix matching on the tokens to find relevent desktop files.
Right now this is implemented as a hashtable that we iterate over,
checking prefixes on each token. This could possibly be sped up by
creating an array, but it's already pretty fast...
https://bugzilla.gnome.org/show_bug.cgi?id=711557
...so that the generated code will build on all platforms, as compilers
like Visual C++ does not like #ifdef checks during a definition/use of
a macro.
https://bugzilla.gnome.org/show_bug.cgi?id=711049
In each DesktopFileDir, store a list of desktop files for that
directory. This speeds up opening desktop files by name because we can
skip statting in directories that we know don't have the file and also
speeds up _get_all() because we can avoid enumeration.
This also improves our support for dealing with names like
'kde4/kate.desktop' (equivalent to kde4-kate.desktop) since we find out
about all of these files are the start and don't need to guess about
which '-' to change to a '/'. It also means that we can easily deal
with more than one level of such prefixes.
We use a file monitor to watch for changes, invalidating our lists when
we notice them.
https://bugzilla.gnome.org/show_bug.cgi?id=711520
Include unistd.h only on *NIX and define items as necessary on Windows,
also replace instances of ssize_t with the GLib-equivilant gssize so to fix
the build on platforms that do not have ssize_t, such as Visual C++.
https://bugzilla.gnome.org/show_bug.cgi?id=711047
We need to use g_content_type_get_mime_type() to look up the mime type of
the file from the registry on the content type that was acquired on
Windows, as g_file_info_get_content_type() does not acquire the
file mime type (unlike on *NIX).
g_content_type_get_mime_type() on *NIX is more or less an no-op as it
simply returns the g_strdup()-ed version of the passed-in content type.
This will enable the resources test to pass on Windows.
https://bugzilla.gnome.org/show_bug.cgi?id=711047
The overridden implementation of the skip method for
GLocalFileInputStream allows skipping past the end of the file which is
inconsistent with the documentation. Prevent this by first seeking to
the end of the file and then seeking backwards from there as much as
is necessary.
https://bugzilla.gnome.org/show_bug.cgi?id=711048
If the goal is to make sure we don't have a dbus connection, it has
to call g_test_dbus_unset() instead which is much more complete.
In this case, g_test_dbus_unset() is called already, so it should be
fine.
https://bugzilla.gnome.org/show_bug.cgi?id=697348
This is to avoid having again the subtil bug in dbus-appinfo.c:
session_bus_down() was called before g_test_run() so the test was
running on the user's dbus session.
https://bugzilla.gnome.org/show_bug.cgi?id=697348
A reference to the session bus is now stored in GNotificationBackend.
Remove the extraneous one in the gtk backend and stop using it in
withdraw_notification.
https://bugzilla.gnome.org/show_bug.cgi?id=711051
Don't hold the lock when calling the user's callback during
g_cancellable_connect() for the case that the cancellable has already
fired.
Taken from a patch by Alex Larsson.
Doc updates from Colin Walters.
https://bugzilla.gnome.org/show_bug.cgi?id=705395
If someone calls org.gtk.Actions.Describe on a non-existent action then
return an exception instead of a trivial description (disabled, no
state, etc.).
https://bugzilla.gnome.org/show_bug.cgi?id=687185
If someone calls org.gtk.Actions.Describe on a non-existent action then
return an exception instead of a trivial description (disabled, no
state, etc.).
https://bugzilla.gnome.org/show_bug.cgi?id=687185
g_object_set() allowed us to bypass the usual checks that the state
doesn't change type and also leaked.
Fix that up by turning the state into a construct property (so that it
always gets set once during construction, even if only to NULL) and
then route the further sets through the C API so that they are subject
to the same checks.
https://bugzilla.gnome.org/show_bug.cgi?id=696424
Ignore qualified (in the XML namespace sense) tags and attributes when
compiling GSettings schemas.
This will allow people to add custom tags and attributes to their schemas
without tripping up the compiler.
https://bugzilla.gnome.org/show_bug.cgi?id=635641
Ignore qualified (in the XML namespace sense) tags and attributes when
parsing D-Bus introspection XML.
This will allow people to add custom tags and attributes to their D-Bus
interfaces without tripping up GDBus.
https://bugzilla.gnome.org/show_bug.cgi?id=665634
Stop using the recently-deprecated GSettings APIs.
Use the GSettingsSchema-based APIs instead.
This fixes a number of bugs and also a net reduction of code. In
particular, list-schemas will now work in context of a given --schemadir
argument.
https://bugzilla.gnome.org/show_bug.cgi?id=695558
The number of arguments passed to each function is about to increase, so
just use global variables instead.
This is a commandline tool, after all...
https://bugzilla.gnome.org/show_bug.cgi?id=695558
Add g_settings_schema_has_key() and _get_range(), _range_check(),
_get_value_type(), _get_default_value() methods on GSettingsSchemaKey.
Deprecate the equivalent APIs on GSettings.
https://bugzilla.gnome.org/show_bug.cgi?id=683017
Add two new APIs: g_settings_get_user_value() and
g_settings_get_default_value(). Together, these should allow the
inspection of all interesting cases of "is this key set?" and "what
would happen if I reset this key?"
https://bugzilla.gnome.org/show_bug.cgi?id=668233
Add two boolean parameters to our internal getter utility function in
anticipation of the coming addition of g_settings_get_user_value() and
g_settings_get_default_value() APIs.
https://bugzilla.gnome.org/show_bug.cgi?id=668233
This will get the 'user' value from the database (ie: the one that the user has
control over).
Provide a default implementation that chains to ->read(). That will work for
all of our internal backends which don't have a concept of layering or
lockdown.
The delayed backend implments "user value" by returning anything that's
in the changeset (incuding an explicit NULL) or chaining up otherwise.
We will use this for g_settings_get_user_value().
https://bugzilla.gnome.org/show_bug.cgi?id=668233
The G_ADD_PRIVATE() macro, and the auto-generated get_instance_private()
internal function, should be used conditionally depending on the maximum
allowed version of GLib, as defined by the GLIB_VERSION_MAX_ALLOWED
pre-processor symbol.
This allows generating code that can be compiled in projects that wish
to use an older API version of GLib through the use of the
GLIB_VERSION_MAX_ALLOWED symbol.
https://bugzilla.gnome.org/show_bug.cgi?id=710133
Prevent a crash in the case that gvdb_table_list() returns NULL (ie:
because a schema has no keys).
Stop a memory leak caused by pointlessly stealing keys from a hashtable
(after we quarked them already).
Stop allocating an extra entry at the end of an array for a terminator
(that we never wrote anyway) when all functions using this API refer to
the out-parameter length array.
https://bugzilla.gnome.org/show_bug.cgi?id=711016
Ignore the keyfile being deleted (ie: by the user) instead of reporting
it to the application as all values being reverted back to their
originals.
https://bugzilla.gnome.org/show_bug.cgi?id=637956
Support the 'extends' attribute that has been supported by the compiler
for a long time by doing three things:
- when creating a schema that extends another schema, lookup that other
schema
- when looking up keys and we can't find them in the schema, check
(recursively) in the 'extends' schema
- when listing all keys in a schema, also visit the extends schemas,
but take care to avoid duplicates caused by overrides
Extend the testsuite to verify that it works.
https://bugzilla.gnome.org/show_bug.cgi?id=645453
g_settings_list_schemas() and g_settings_list_relocatable_schemas() are
now deprecated.
This will allow listing off schemas on non-default sources and is a
better fit with the new direction the API is going.
https://bugzilla.gnome.org/show_bug.cgi?id=680838
Add an API to read the summary and description from the .xml schema
files.
This will be used by dconf-editor and gnome-tweak-tool.
This API is a bit heavy -- it parses the XML and builds a table. It
also loads gettext domains for translation. It only does these things
if it is used, however, so it will not impact normal applications.
We store the summary/description in a pair of hash tables on the schema
source (which we have a backref to as of a few commits ago). We can't
use a global table because people might want to request summary and
description from non-default sources. We don't want to use per-schema
tables because we'd have to reparse the directory every time (since we
cannot guess which file a schema may have been in).
https://bugzilla.gnome.org/show_bug.cgi?id=668232
Take this private API and make it public along with a boxed type and
ref/unref functions.
Future commits will add accessors with new functionality and some that
allow us to deprecate functions on GSettings itself (such as
g_settings_get_range).
https://bugzilla.gnome.org/show_bug.cgi?id=668232
The way we created the global schema list predates
g_settings_schema_source_new_from_directory() and therefore doesn't use
it.
Update it to use that function, removing some code.
https://bugzilla.gnome.org/show_bug.cgi?id=668232
If a broken (or malicious) remote client calls Open or CommandLine
on a GApplication that does not implement those, return a DBus
error instead of going through and then emitting a warning.
https://bugzilla.gnome.org/show_bug.cgi?id=710885
This code was added for use by the G_FILE_ATTRIBUTE_THUMBNAIL_IS_VALID
file attribute, but may end up being used elsewhere (e.g. in GVfs) as well.
As it’s dealing with untrusted external files, and the non-trivial PNG file
format, this commit adds several test cases to cover valid and invalid PNG
files.
The security model for the thumbnail verification code is that the user’s
cache directory is untrusted, and potentially any PNG file which is passed
to the verifier has been manipulated arbitrarily by an attacker.
This is a follow-up to commit fe7069749f.
https://bugzilla.gnome.org/show_bug.cgi?id=709898
This indicates whether the thumbnail (given by G_FILE_ATTRIBUTE_THUMBNAIL_PATH)
is valid — i.e. to represent the file in its current state. If
G_FILE_ATTRIBUTE_THUMBNAIL_IS_VALID is FALSE (for a normal _or_ failed
thumbnail) it means the file has changed since the thumbnail was generated, and
the thumbnail is out of date.
Part of checking thumbnail validity (by the spec) involves parsing
headers out of the thumbnail .png so we include some (small) code to do
that in a separate file. We will likely want to copy this code to gvfs
to do the same for GVfsFile.
Heavily based on a patch from Philip Withnall <philip.withnall@collabora.co.uk>
who suggested the feature and designed the API.
https://bugzilla.gnome.org/show_bug.cgi?id=709898
It is our intention that memory output streams should operate in two
distinct modes, depending on if a realloc function was provided or not.
In the case that we have a realloc function (resizable mode), we want
the stream to behave as if it were a file that started out empty. In
the case that we don't have a realloc function (fixed-sized mode), we
want the stream to behave as a block device would.
To this end, we introduce two changes in functionality:
- seeking to SEEK_END on a resizable stream will now seek to the end of
the valid data region, not to the end of the allocated memory (which
is really just an implementation detail)
- seeks past the end of the allocated memory size are now permitted,
but only on resizable streams. The next write will grow the buffer
(inserting zeros between).
Some tweaks to testcases were required in order not to break the build,
which indicates that this is an API break, but it seems unlikely that
anyone will be effected by these changes 'in the real world'.
Updates to documentation and further testcases are in following commits.
Based on a patch from Maciej Piechotka <uzytkownik2@gmail.com>.
https://bugzilla.gnome.org/show_bug.cgi?id=684842
Introduce the concept of "fixed" vs. "resizable" streams and document
how g_seekable_seek() works for each case.
We don't include g_seekable_is_fixed_size() at this point because we
don't know if anyone would require it. This may appear in the future if
someone asks for it, however.
https://bugzilla.gnome.org/show_bug.cgi?id=684842
D-Bus versions < 1.6.18 (i.e. all current versions) have a bug with the
path_namespace='/' match rule key. It should conceptually match everything,
but actually matches nothing. This results in no property change (or other)
signals being forwarded to the D-Bus client.
The work-around implemented in GDBusObjectManagerClient is to remove the
path_namespace match key if its value is ‘/’.
For the upstream D-Bus bug, see:
https://bugs.freedesktop.org/show_bug.cgi?id=70799https://bugzilla.gnome.org/show_bug.cgi?id=710726
Move a method from GNotificationBackend into the fdo backend (since it
was only used from here). Remove the accessors for the already-public
(in private header) ->dbus_connect and ->application on
GNotificationBackend.
https://bugzilla.gnome.org/show_bug.cgi?id=688492
g_buffered_input_stream_finalize() is already declared as static in this
gbufferedinputstream.c file, so just remove the redundant declaration.
Signed-off-by: Djalal Harouni <tixxdz@opendz.org>
https://bugzilla.gnome.org/show_bug.cgi?id=710345
Replaced several usages of GError with g_return_val_if_fail() for
developer-only messages. As additional value, it also removes those
messages from the list to translate, simplifying translator's work a
bit.
https://bugzilla.gnome.org/show_bug.cgi?id=569017
Over many years of writing code interacting with subprocesses, a pattern
that comes up a lot is to run a child and get its output as UTF-8, to
put inside a JSON document or render in a GtkTextBuffer, etc.
It's very important to validate at the boundaries, and not say deep
inside Pango.
We could do this a bit more efficiently if done in a streaming fashion,
but realistically this should be OK for now.
We weren't closing the streams after we were done reading or writing,
which is kind of essential. The easy way to fix this is to just use
g_output_stream_splice() to a GMemoryOutputStream rather than
hand-rolling it. This results in a substantial reduction of code
complexity.
A second serious issue is that we were marking the task as complete when
the process exits, but that's racy - there could still be data to read
from stdout. Fix this by just refcounting outstanding operations.
This code, not surprisingly, looks a lot like the "multi" test.
Next, because processes output binary data, I'd be forced to annotate
the char*/length pairs as (array) (element-type uint8). But rather than
doing that, it's *far* simpler to just use GBytes.
We need a version of this that actually validates as UTF-8, that will be
in the next patch.
There are a number of nice things this class brings:
0) Has a race-free termination API on all platforms (on UNIX, calls to
kill() and waitpid() are coordinated as not to cause problems).
1) Operates in terms of G{Input,Output}Stream, not file descriptors
2) Standard GIO-style async API for wait() with cancellation
3) Makes some simple cases easy, like synchronously spawning a
process with an argument list
4) Makes hard cases possible, like asynchronously running a process
with stdout/stderr merged, output directly to a file path
Much rewriting and code review from Ryan Lortie <desrt@desrt.ca>
https://bugzilla.gnome.org/show_bug.cgi?id=672102
This is essentially a commandline implementation of the client-side of
the org.freedesktop.Application D-Bus interface.
It includes support for tab-completion based on desktop files and their
contents.
https://bugzilla.gnome.org/show_bug.cgi?id=704218
The GApplicationCommandLine DBus implementation currently calls
g_dbus_method_invocation_return_value() in its finalize() implementation
only, relying on the object being destroyed after g_object_unref() is
called on it inside g_application_impl_method_call().
While this is usually fine for C applications, when overriding the
command_line vfunc from language bindings, the binding might add extra
references to the object, which might not be released immediately - e.g.
because they're garbage collected, or possibly even leaked. The same
scenario could happen in a C application that decides to keep a
reference to the passed-in GApplicationCommandLine object.
To ensure the CommandLine DBus method always gets a reply after the
invocation of command_line in the primary instance, explicitly send the
message back before dropping our reference to the object.
https://bugzilla.gnome.org/show_bug.cgi?id=708042
It's not difficult to do; not all backends implement it, and for some
it may be difficult to implement query_info_on_read(), so let's just
do both.
https://bugzilla.gnome.org/show_bug.cgi?id=706254
Since it could confuse callers (admittedly who are already violating
a precondition).
Just spotted while adapting some bits of this code for a ssh library.
This commit factors out a function for comparing string suffixes, and at
the same time makes it safe for mime types that are shorter than the
"/*" suffix.
==25418== Invalid read of size 1
==25418== at 0x3C6D0F9D22: __gio_xdg_cache_mime_type_subclass (xdgmimecache.c:848)
==25418== by 0x3C6D09ED8C: g_content_type_is_a (gcontenttype.c:158)
==25418== by 0x34D8031E95: gtk_recent_filter_filter (gtkrecentfilter.c:733)
==25418== by 0x34D802F167: _gtk_recent_chooser_get_items (gtkrecentchooserutils.c:387)
==25418== by 0x34D802D07F: idle_populate_func (gtkrecentchoosermenu.c:1011)
==25418== by 0x34D7A20477: gdk_threads_dispatch (gdk.c:804)
==25418== by 0x3C6C0492F5: g_main_context_dispatch (gmain.c:3065)
==25418== by 0x3C6C049677: g_main_context_iterate.isra.23 (gmain.c:3712)
==25418== by 0x3C6C04972B: g_main_context_iteration (gmain.c:3773)
==25418== by 0x34D7FC2AF4: gtk_main_iteration (gtkmain.c:1262)
==25418== by 0x408EB4: main (in /usr/bin/glade)
https://bugzilla.gnome.org/show_bug.cgi?id=708529
Rather than having lots of obscure platform-based #ifdefs all over
gio, define some macros in gcredentialsprivate.h, and use those to
simplify the rest of the code.
https://bugzilla.gnome.org/show_bug.cgi?id=701482
Sometimes the application doesn't want to autostart a service
when it creates a proxy, but wants the service autostarted when
it makes the first method call. Allow that behavior with a new
flag.
https://bugzilla.gnome.org/show_bug.cgi?id=708828
Fix up a lot of whitespace issues in this file since we're about to do
some pretty serious rewriting here anyway...
Add some fold markers while we're at it.
Change the search path to be a global array of 'DesktopFileDir' structures and
change the 'get' function to an 'ensure' function.
This is just a straight-up refactor. Future patches will expand the
DesktopFileDir structure.
Add a convenient and race-free method of watching local files from the
GLib worker thread.
Without this, the race-free way to create a monitor that dispatches
events to the worker thread looked something like this:
- dispatch an idle to the worker thread
- from the idle, create the monitor and connect signals
- from the original thread, wait (on a cond?) until the worker thread
has finished setting up the monitor
- read the file that you were monitoring
which is just ridiculously complicated...
To use the new API:
monitor = g_local_file_monitor_new_in_worker ("/path/to/some/file",
G_FILE_MONITOR_NONE,
&error);
g_assert_no_error (error);
g_signal_connect (monitor, "changed", G_CALLBACK (callback), NULL);
g_local_file_monitor_start (monitor);
'callback' will run from the GLib worker thread.
This is the reason that the start() call was introduced in the previous
commit. The backends that don't use the start() call will have a very
thin race between creating the monitor and connecting the signal, but
hopefully they will be fixed soon.
These new APIs will be used (at least) from gdesktopappinfo to watch for
changes in the desktop file directories.
https://bugzilla.gnome.org/show_bug.cgi?id=704887
and start using the new start() vcall on the local monitor classes.
I only port inotify because I am uncomfortable making changes to the
other monitor backends without having a way of testing them.
https://bugzilla.gnome.org/show_bug.cgi?id=704887
Stop abusing constructor() to do startup work, adding _start() calls
instead.
The backends themselves still use constructor() although a patch will be
following to also fix inotify.
The reason for using a separate start() call instead of constructed()
will become apparent in future commits.
https://bugzilla.gnome.org/show_bug.cgi?id=704887
During initialisation of a directory monitor with the
G_FILE_MONITOR_WATCH_MOUNTS flag set, GLocalDirectory monitor will add a
UNIX mount watch in case the file notification backend doesn't support
reporting these events for itself.
Unfortunately, it was performing the check incorrectly, resulting in a
monitor always being added.
Fix that, and add the #define for G_LOCAL_DIRECTORY_MONITOR_GET_CLASS()
that was also missing (since the fix depends on it).
https://bugzilla.gnome.org/show_bug.cgi?id=704882
Matthew Barnes noted this on IRC a few days ago. I just had this file
open for other reasons and decided to tweak the docs to make this trap
more clear.
https://bugzilla.gnome.org/show_bug.cgi?id=709301
Don't return children with invalid schemas from
g_settings_list_children() (ie: missing schemas or mismatched paths).
This prevents gsettings list-recursively from crashing when broken
schemas are installed on the system.
https://bugzilla.gnome.org/show_bug.cgi?id=705688
There are some corner cases where using the sync version of read/write
in a thread could cause thread-safety issues. In these cases it's
possible to override the output stream's splice_async() function,
but for input streams one would need to do some acrobatics to
stay thread-safe. Alternatively, some implementations may not even
override their sync read/write functions.
This patch refactors the default splice_async() implementation to
call the sync read and write functions in a thread only when both
async versions are thread-based. When one or both are non-threaded,
it calls the virtual write_async() and read_async() functions of the
involved streams within the same thread.
https://bugzilla.gnome.org/show_bug.cgi?id=691581
Refactor g_output_stream_close_async() into itself and an internal
variant for potential use inside other operations (splice_async).
The internal version must be called between
g_output_stream_set_pending() and g_output_stream_clear_pending().
https://bugzilla.gnome.org/show_bug.cgi?id=691581
Previously, no testcases tested the close flags of
g_output_stream_splice_async. This patch adds tests for that and
also tests various combinations of threaded and non-threaded
GInputStream async reads and GOutputStream async writes.
https://bugzilla.gnome.org/show_bug.cgi?id=691581
In implementing a better g_output_stream_splice_async() and possibly
other situtations it's helpful to know whether the output stream's
write function internally uses threads. If it and the input stream's
read async functions use threads, then the splice function could
spawn a single thread for better efficiency.
This patch adds a function to determine whether an output stream's
g_output_stream_write_async() function internally uses threads.
https://bugzilla.gnome.org/show_bug.cgi?id=691581
In implementing a better g_output_stream_splice_async() and possibly
other situtations it's helpful to know whether the input stream's
read function internally uses threads. If it and the output stream's
write async functions use threads, then the splice function could
spawn a single thread for better efficiency.
This patch adds a function to determine whether an input stream's
g_input_stream_read_async() function internally uses threads.
https://bugzilla.gnome.org/show_bug.cgi?id=691581
Rather than always calling out to g_file_get_path() (which
might block, whatever the documentation might say), postpone
the call until we actually need it.
https://bugzilla.gnome.org/show_bug.cgi?id=708753
g_cancellable_disconnect will wait until any pending "cancelled"
handlers finish. This is useful because disconnecting a handler can have the
side-effect of freeing data that the cancelled handler may rely on.
Unfortunately, the code used to enforce this synchronization between
"cancelled" handlers and g_cancellable_disconnect will also cause
deadlock if the cancelled handler itself calls g_cancellable_disconect.
Obviously, if g_cancellable_disconnect is explicitly called by a "cancelled"
handler, then the "cancelled" handler is shouldering the responsibility
of not using any data that may be freed by disconnection.
Also, g_cancellable_disconnect can be called in unexpected places by
lower layers in the code (for instance as a result of g_source_destroy).
In practice, this means it's easy for deadlocks to inadvertently crop
up when using "cancelled" handlers.
For these reasons, it would be good to fix the deadlock.
This commit prevents the deadlock by allowing foregoing synchronization,
if a pending "cancelled" handler is in the same thread as the
g_cancellabale_disconnnect call.
https://bugzilla.gnome.org/show_bug.cgi?id=705395
In the real_..._async wrapper for GFile.measure_disk_usage, skip the
wrapping of the progress callback in the case that the user gave a NULL
callback to the async function. This is a performance improvement
because the sync version won't have to do continuous sampling of the
clock to issue a call to the wrapper which will then do nothing.
Unfortunately, I made this simplifying assumption when writing the
wrapper, but forgot to actually implement it when making the sync call.
As a result, the wrapper is still called, and invokes the NULL callback,
causing a segfault.
Make sure we pass NULL if the user's callback was NULL.
https://bugzilla.gnome.org/show_bug.cgi?id=707787
Make use of __wgetmainargs() on Windows so that we can get wide char
versions of the argv's that are passed in when this test program is being
invoked. This is necessary as one might enter non-ASCII, such as
CJK characters filenames and/or directories to run the test program
against, so that we can process the name(s) and pass the proper
UTF-8-encoded name(s) of the files/directories that is being tested.
https://bugzilla.gnome.org/show_bug.cgi?id=707787
It turns out that although dirent is available on mingw32 (where the
code was originally tested), it is not usable from MSVC.
Avoid portability problems by just using GDir.
Also, be careful about ensuring that we utf8-format filenames in our
error messages, and leave out the "file://" component since the strings
we're displaying are not URIs (and we don't want to make them URIs since
the extra escaping would reduce legibility).
Thanks to Chun-wei Fan <fanchunwei@src.gnome.org> for portions of this
patch and for reviews.
https://bugzilla.gnome.org/show_bug.cgi?id=707787
Virtaal installs a mime package for various .po-like file formats, one
of which has the extension .txt. This causes GLib to report ".txt"
files still as "text/plain" but no longer with complete certainty.
The result is that asserting !uncertain during the testsuite causes the
test to fail if Virtaal happens to be installed.
Remove this assertion.
On Windows and OS X, FIONREAD on a UDP socket gets the total number of
bytes available, not the number of bytes available in the next packet,
which is the more useful number (and how the function always behaved
on Linux).
On OS X, fix this by using SO_NREAD. On Windows, fix this by doing a
MSG_PEEK recv() into a giant buffer, since there is apparently no
other way to get the information.
https://bugzilla.gnome.org/show_bug.cgi?id=686786
The requested_conditions list access is not threadsafe. When passing
the socket ownership from a GSource callback to another thread, which
also creates a GSocketSource for the socket, it can happen that the
original GSocketSource is finalized at the same time as the new one
is created. This would cause inconsistencies in the requested_conditions
list and can cause assertions or completely undefined behaviour.
https://bugzilla.gnome.org/show_bug.cgi?id=705027
The RunDLL command call during get_session_address_dbus_launch() was
expecting _g_win32_run_session_bus@16 and g_win32_run_session_bus
on Win32 and Win64 respectively at least when GLib is compiled with MSVC,
not g_win32_run_session_bus@16, which caused annoying RunDLL error dialogue
boxes to show up during the use of GtkApplication (such as when running
gtk3-demo-application on Windows), prevented GtkApplication items from
being run for more than one time during the lifespan of the program,
and this also interfered with some GTK+ tests, causing them to fail.
Update accordingly to address the issue.
GNetworkAddress was allowing IPv6 scope ids in g_network_address_new()
/ g_network_address_parse(), but not in g_network_address_parse_uri().
Fix that.
Part of https://bugzilla.gnome.org/show_bug.cgi?id=669724
Convert {glib,gobject,gio}/tests to use the automake TAP driver
and test harness instead of gtester. To do so, we add a glib-tap.mk
that provides the same interface as glib.mk, except for the
reporting and coverage testing functionality. Eventually, we may
want to replace glib.mk with it. I've not yet converted the
toplevel tests/ directory, since it mixes gtestutils tests with
other binaries.
https://bugzilla.gnome.org/show_bug.cgi?id=692125
With UDP sockets, g_socket_bind() with allow_reuse=TRUE on Linux
behaved in a way that the documentation didn't suggest, and that
didn't match other OSes. (Specifically, it allowed binding multiple
multicast sockets to the same address.)
Since this behavior is useful, and since allow_reuse didn't have any
other meaning with UDP sockets, update the docs to reflect the Linux
behavior, and make it do the same thing on non-Linux.
https://bugzilla.gnome.org/show_bug.cgi?id=689245
Under C locale, open() in Python 3 sets the file encoding to ASCII.
As expat looks at encoding="..." in XML declaration, gdbus-codegen can
simply open the input file as binary and let expat decode the content.
https://bugzilla.gnome.org/show_bug.cgi?id=696633
When running a task in a thread, GTask may still be internally holding
a ref on the task in that thread even after the callback is called in
the original thread (depending on thread scheduling). Fix the test to
handle that by using a weak notify that signals a GCond, and wait for
that GCond from the main thread. (And add a corresponding check to
test_return_on_cancel().)
https://bugzilla.gnome.org/show_bug.cgi?id=705152
When an icon is requested as symbolic, our generic fallback algorithm
uses fullcolor icons when the specified icon name is not found, treating
the "-symbolic" suffix as another component of the icon name.
Change the algorithm to check beforehand if the icon is symbolic, remove
the suffix if so, and re-add it at the end for all the generated icon
names.
https://bugzilla.gnome.org/show_bug.cgi?id=680926
GFileMonitor takes great care to sample the thread-default main context
at the time that it is created in order that events can be dispatched to
the correct thread when they come in.
The inotify GFileMonitor implementation uses a global file descriptor
shared between all watches. It has to poll this file descriptor from
somewhere so it arbitrarily picks the default main context.
The problem with that is that the user might not be running it.
Let's use the GLib worker thread for this instead. It's guaranteed to
be running if you need it, and this is exactly the sort of problem it
was meant to solve.
https://bugzilla.gnome.org/show_bug.cgi?id=704873
The default GNOME 3.10 login process right now has gdm spawn a session
for the login screen, retaining the X server, but closing the session
bus. Right now in this scenario many GNOME components such as
gnome-settings-daemon attempt to "clean up" on shutdown by releasing
their owned names.
But they're shutting down because the session bus went away, so
releasing the name is pointless, and presently spews an error into the
journal.
This patch avoids that error spew, which helps system administrators
find *real* problems.
https://bugzilla.gnome.org/show_bug.cgi?id=704567
Add a missing Name entry, and add a terminal ; to the Actions
entry in org.gtk.test.dbusappinfo.desktop. desktop-file-validate
still contains about the DBusActivatable entry and about the
missing Exec entries. The former will go away when desktop-file-validate
gets updated for the latest spec revision.
Update GCancellableSource to call g_source_set_ready_time() when its
cancellable is cancelled, rather than manually checking the state of
the cancellable from prepare() and check().
This means that we now need to use g_cancellable_connect() rather than
g_signal_connect() at construction time, to avoid the connect/cancel
race condition. Likewise, use g_cancellable_disconnect() to avoid the
disconnect/cancel race condition when freeing the source. (In fact,
that was necessary in the earlier code as well, and might have
occasionally caused spurious criticals or worse.)
https://bugzilla.gnome.org/show_bug.cgi?id=701511
GPollableSource and GSocket's "broken" source never trigger on their
own, so with the changes to GSources in the last cycle, their check
and prepare functions are unnecessary (and undesired).
https://bugzilla.gnome.org/show_bug.cgi?id=701511
The unix input/output streams were using a gio-only source type that
was mostly identical to GUnixFDSource. Get rid of that source type
and just use GUnixFDSource instead.
https://bugzilla.gnome.org/show_bug.cgi?id=701511
For the glib-defined source types, and any source type that defines a
closure callback but not a closure marshal, use
g_cclosure_marshal_generic. And then remove all the other remaining
source closure marshals.
https://bugzilla.gnome.org/show_bug.cgi?id=701511
A counterpart for parsing of detailed actions into (name, target) pairs,
this new function prints them back.
We also add a new function to check for validity of action names. Only
valid action names are allowed when printing. Parsing accepts _some_
invalid names for backwards compatibility.
https://bugzilla.gnome.org/show_bug.cgi?id=704157
If the default route is via a device rather than a particular IP
address, then neither RTA_DST nor RTA_GATEWAY will be present in the
RTM_NEWROUTE message, and so GNetworkMonitorNetlink would ignore it,
and then think there was no default route. (This could happen with
certain kinds of VPNs, if they were set to route all traffic through
the VPN.)
Fix this by recognizing routes that specify RTA_OIF ("output
interface") instead of RTA_GATEWAY.
https://bugzilla.gnome.org/show_bug.cgi?id=701609
Add a fairly realistic testcase that ensures that GDesktopAppInfo with
DBusActivatable=true can successfully talk to GApplication for a variety
of purposes.
https://bugzilla.gnome.org/show_bug.cgi?id=699259
A previous version of the patch had OnlyShowIn support for desktop file
actions. This was removed from the spec and the patch rewritten, but
this bit of documentation slipped through. Remove it.
For some time, the desktop file specification has supported "additional
application actions". This is intended to allow for additional methods
of starting an app, such as a mail client having a "Compose New Message"
action that brings up the compose window instead of the folder list.
This patch adds support for this with a relatively minimal API.
In the case that the application is a GApplication and DBusActivatable,
desktop actions are translated into GActions that have been added to the
application with g_action_map_add_action(). This more or less closes
the loop on being able to activate an application with an action
invocation (instead of 'activate').
https://bugzilla.gnome.org/show_bug.cgi?id=664444
Add a new type of GAction that represents the value of a property on an
object. As an example, this might be used on the "visible-child-name"
property of a GtkStack.
https://bugzilla.gnome.org/show_bug.cgi?id=703270
It's possible to get a org.freedesktop.Properties.GetAll call even if we
have no readable properties in the introspection, in which case we
should return the empty list in the usual way.
We should certainly _not_ be dispatching to the method call handler of
an interface which has no properties (since it will not be expecting
this).
Add a check to make sure that there is at least one readable property
before assuming that a NULL get_property handler implies that we want to
handle properties asynchronously.
Add a testcase that was failing before the change and works after it.
https://bugzilla.gnome.org/show_bug.cgi?id=703437
We don't use # or other forms of links in the section headings.
We also capitalize them and don't put a final period.
This commit corrects several headings to follow these rules.
As it turns out, we have examples of internal functions called
type_name_get_private() in the wild (especially among older libraries),
so we need to use a name for the per-instance private data getter
function that hopefully won't conflict with anything.
cd html && gtkdoc-mkhtml $mkhtml_options gio ../gio-docs.xml
../xml/gdbusconnection.xml:2063: parser error : Opening and ending tag mismatch: literal line 2062 and para
</para>
^
We do a bunch of new validity checks for return values in response to
calls on the D-Bus property API but we miss the 'goto out' in one case.
Add it.
https://bugzilla.gnome.org/show_bug.cgi?id=698375
Add some type checking for the values returned from async property
handling calls, similar in spirit to the type checking we do for normal
method calls.
https://bugzilla.gnome.org/show_bug.cgi?id=698375
The existing advice in the documentation to "simply" register the
"org.freedesktop.DBus.Properties" interface if you want to handle
properties asynchronously is pretty unreasonable. If you want to handle
this interface you have to deal with all properties for all interfaces
on the path, and you have to do all of the checking for yourself. You
also have to provide your own introspection data.
Introduce a new convention for dealing with properties asynchronously.
If the user provides NULL for their get_property() or set_property()
functions in the vtable and has properties registered then the
properties are sent to the method_call() handler. We get lucky here
that this function takes an "interface_name" parameter that we can set
to "org.freedesktop.DBus.Properties".
We also do the user the favour of setting the GDBusPropertyInfo on the
GDBusMethodInvocation for their convenience (for much the same reasons
as they might want the already-available GDBusMethodInfo).
Add a testcase as well as a bunch of documentation about this new
feature.
https://bugzilla.gnome.org/show_bug.cgi?id=698375
Separate the code for validating a method call from the code for
actually scheduling it for dispatch.
This will allow property Get/Set/GetAll calls to be dispatched to the
method_call handler without duplicating a lot of code.
https://bugzilla.gnome.org/show_bug.cgi?id=698375
We presently do a lot of checks on property sets (signature check,
correct interface, property exists, etc.) from the worker thread before
dispatching the call to the user's thread. The typecheck, however, is
saved until just before calling the user's vfunc, in their thread.
My best guess is that this was done to save having to unpack the value
from the tuple twice (since we don't unpack it until we're just about
the call the user).
This patch moves the check to the same place as all of the other checks.
The purpose of this change is to allow for sharing this check with the
(soon-to-be-introduced) case of handing property sets from
method_call().
This change has a minor side effect: error messages generated by sending
invalid values to property sets are no longer guaranteed to be correctly
ordered with respect to the void returns from successful property sets.
They will instead be correctly ordered with respect to the other error
messages.
https://bugzilla.gnome.org/show_bug.cgi?id=698375
When parsing an address, we need to re-set "len" between IPv4 and
IPv6, since WSAStringToAddress() might set it to sizeof(struct sin_addr)
when trying to parse the string as IPv4, even if it fails. Also, we
need to make sure to not pass strings to WSAStringToAddress() that it
will accept but that we don't want it to.
When stringifying an address, we need to clear the sockaddr before
filling it in, so we don't accidentally end up with an unwanted
scope_id or the like.
https://bugzilla.gnome.org/show_bug.cgi?id=701401
Previously, g_file_copy() would (on Unix) create files with the
default mode of 644. For applications which might at user request
copy arbitrary private files such as ~/.ssh or /etc/shadow, a
world-readable copy would be temporarily exposed.
This patch is suboptimal in that it *only* fixes g_file_copy()
for the case where both source and destination are instances of
GLocalFile on Unix.
The reason for this is that the public GFile APIs for creating files
allow very limited control over the access permissions for the created
file; one can either say a file is "private" or not. Fixing
this by adding e.g. g_file_create_with_attributes() would make sense,
except this would entail 8 new API calls for all the variants of
_create(), _create_async(), _replace(), _replace_async(),
_create_readwrite(), _create_readwrite_async(), _replace_readwrite(),
_replace_readwrite_async(). That can be done as a separate patch
later.
https://bugzilla.gnome.org/show_bug.cgi?id=699959
Previously, we called g_file_query_info() *again* on the source at the
very end of the copy. This has the lame semantics that if the source
happened to be deleted, we would fail to apply attributes to the
destination. This could even be a security flaw.
This commit changes things so that we query info from the source
*stream* after opening - i.e. on Unix we use the proper fstat() and
friends. That way we operate more atomically.
https://bugzilla.gnome.org/show_bug.cgi?id=699959
The freedesktop application specification is largely overlapping the
GLib application D-Bus interface but implementing it will allow for
applications to be launched directly from desktop files, which we want.
We keep the old Gtk interface for compatibility reasons and because it
has some functionality not in the freedesktop spec (Busy state,
CommandLine, etc.).
https://bugzilla.gnome.org/show_bug.cgi?id=699259
Since services are based on D-Bus activation and desktop files are
supposed to be named like the busname for DBusActivatable applications
and since gnome-shell wants wmclass equal to the desktop file name, we
therefore want wmclass equal to the application ID in this case.
wmclass is determined from the prgname, which is otherwise pretty
pointless to set to some random thing in $(libexec) for a D-Bus service,
so set that to the appid.
This means that for D-Bus services, the following things are now all the
same:
- application ID
- prgname
- wmclass property set on all windows
- desktop file name
- well-known bus name
There are not many applications running as D-Bus services at present so
this shouldn't impact anybody except for gnome-clocks (where this change
will be fixing a bug) and gnome-terminal.
https://bugzilla.gnome.org/show_bug.cgi?id=699259
OS X's getaddrinfo() only supports IPv6 scope IDs that are interface
names, not numbers. So use if_indextoname() to get the name of an
interface and construct an address using that.
https://bugzilla.gnome.org/show_bug.cgi?id=700123
In the case that HAVE_DBUS_DAEMON was undefined (as in ostree where glib
is built before D-Bus) this test was failing. Move it inside the
HAVE_DBUS_DAEMON block.
Remove the complications that were introduced in an attempt to make the
gsettings and gschema-compile tests function as installed tests. These
tests are designed (in large part for gsettings and entirely for
gschema-compile) to test the in-tree tools and should not be testing the
system versions.
In the future we may want to move the use of the in-tree tools from the
gsettings testcase into the Makefile and install the resulting files,
allowing this testcase to run against those files, installed.
Perform a substantial cleanup of the build system with respect to
building and installing testcases.
First, Makefile.decl has been renamed glib.mk and substantially
expanded. We intend to add more stuff here in the future, like canned
rules for mkenums, marshallers, resources, etc.
By default, tests are no longer compiled as part of 'make'. They will
be built when 'make check' is run. The old behaviour can be obtained
with --enable-always-build-tests.
--disable-modular-tests is gone (because tests are no longer built by
default). There is no longer any way to cause 'make check' to be a
no-op, but that's not very useful anyway.
A new glibtests.m4 file is introduced. Along with glib.mk, this
provides for consistent handling of --enable-installed-tests and
--enable-always-build-tests (mentioned above).
Port our various test-installing Makefiles to the new framework.
This patch substantially improves the situation in the toplevel tests/
directory. Things are now somewhat under control there. There were
some tests being built that weren't even being run and we run those now.
The long-running GObject performance tests in this directory have been
removed from 'make check' because they take too long.
As an experiment, 'make check' now runs the testcases on win32 builds,
by default. We can't run them under gtester (since it uses a pipe to
communicate with the subprocess) so just toss them in TESTS. Most of
them are passing on win32.
Things are not quite done here, but this patch is already a substantial
improvement. More to come.
This should be the last users that need to be ported.
For some of the oldschool non-gtester-ified tests, we call g_test_init()
from main() because it is necessary in order to use
g_test_build_filename().
Since this feature is so utterly automake-centric, we may as well be
using the same terminology as automake itself (ie: although it's
BUILT_SOURCES, it's DIST_EXTRA, not DISTED).
Also add some comments to the enum explaining that these terms are
really corresponding directly to the automake terms.
https://bugzilla.gnome.org/show_bug.cgi?id=549783
Both g_[file|bytes]_icon_load() leave the `type' out parameter
untouched, while the async methods g_[file|bytes]_icon_load_finish()
always set it to NULL.
For consistency's sake NULLify it in the sync methods too.
https://bugzilla.gnome.org/show_bug.cgi?id=700725
While those strings ("Expecting 1 control message, got %d" and
"Expecting one fd, but got %d\n") have same singular/plural form
in english, it is not necessarily the case in other languages.
https://bugzilla.gnome.org/show_bug.cgi?id=695233
It's a recipe for race conditions and error; on some hardware
architectures one thread isn't guaranteed to see the results
of writes from another thread without a cache flush.
https://bugzilla.gnome.org/show_bug.cgi?id=700855
The test /gdbus/connection/large_message waits for a dbus name to appear.
The dbus name is created by a another process executed in the background.
If for some reason this fails, the test will likely wait forever.
This will avoid this situation by making the test fail if the dbus service
has not appeared after 10 seconds.
https://bugzilla.gnome.org/show_bug.cgi?id=698981
Back in the far-off twentieth century, it was normal on unix
workstations for U+0060 GRAVE ACCENT to be drawn as "‛" and for U+0027
APOSTROPHE to be drawn as "’". This led to the convention of using
them as poor-man's ‛smart quotes’ in ASCII-only text.
However, "'" is now universally drawn as a vertical line, and "`" at a
45-degree angle, making them an `odd couple' when used together.
Unfortunately, there are lots of very old strings in glib, and also
lots of new strings in which people have kept up the old tradition,
perhaps entirely unaware that it used to not look stupid.
Fix this by just using 'dumb quotes' everywhere.
https://bugzilla.gnome.org/show_bug.cgi?id=700746
It tries to run glib-compile-schemas and glib-mkenums, which
we won't have in the runtime tree.
Anyways it's kind of a dumb test since the best test for
compilation tools is...compiling things, which we already
do frequently.
Although none of the in-tree GSocketConnectable types need it, other
types (like SoupAddress) may find it useful to be able to pass a URI
and a default-port to GProxyAddressEnumerator separately (the same way
you can with GNetworkAddress). So add a default-port property.
https://bugzilla.gnome.org/show_bug.cgi?id=698877
The GError should be initialized to NULL, otherwise we'll
"pile up" errors, then try to free an uninitialized pointer.
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=699493
Not all systems have /usr/bin/true. Some have it in /bin/true.
Instead of trying to guess a hardcoded path to find it, let
g_app_info_create_from_commandline() internally search PATH
to find the program.
https://bugzilla.gnome.org/show_bug.cgi?id=698655
GUnixSocketAddress has some very strange logic for interpreting its
construct paramters. This logic behaves differently in these two cases:
g_object_new (G_TYPE_UNIX_SOCKET_ADDRESS,
"abstract", FALSE,
"address-type", ...,
NULL);
and
g_object_new (G_TYPE_UNIX_SOCKET_ADDRESS,
"address-type", ...,
NULL);
even though the default value for "abstract" is already FALSE.
Change the way the code works so that it is not sensitive to people
merely setting a property to its default value.
https://bugzilla.gnome.org/show_bug.cgi?id=698686
This function takes a GIcon, serialises it and sets the resulting
GVariant as the "icon" attribute on the menu item. We will need to add
a patch to Gtk to actually consume this icon.
Also add G_MENU_ATTRIBUTE_ICON.
https://bugzilla.gnome.org/show_bug.cgi?id=688820
Add support for serialising a GIcon to a GVariant and deserialising the
result back to a GIcon.
This solves a number of problems suffered by the existing to_string()
API, primarily these:
- not forcing the icon to be a utf8 string means that we can
efficiently encode a PNG (ie: just give the array of bytes)
- there is no need to ensure that proper types are loaded before using
the deserialisation interface. 'Foreign' icon types will probably
emit a serialised format the deserialises to a GBytesIcon.
We additionally clearly document what is required for being a consumer
or implementation of #GIcon.
Further patches will be required to GdkPixbuf and GVfsIcon to bring
their implementations in line with the new rules (essentially: introduce
implementations of the new serialize() API).
https://bugzilla.gnome.org/show_bug.cgi?id=688820
GBytesIcon is an icon that has a GBytes inside of it where the GBytes
contains some sort of encoded image in a widely-recognised file format.
Ideally this will be a PNG.
It implements GLoadableIcon, so GTK will already understand how to use
it, but we will add another patch there to make things more efficient.
https://bugzilla.gnome.org/show_bug.cgi?id=688820
Split out the 'simple string format' cases of URIs, file paths and
themed icons to a separate function.
This function will be shared by g_icon_deserialize().
https://bugzilla.gnome.org/show_bug.cgi?id=688820
In the *_async_thread() functions, call the corresponding synchronous
function instead of calling the interface vfunc, which can be NULL.
In some cases the check for the vfunc == NULL was done, but to be
consistent it is better to always call the synchronous version (and the
code is simpler).
https://bugzilla.gnome.org/show_bug.cgi?id=548353
This feature is intended for clients that want to signal a desktop shell
their busy state, for instance because a long-running operation is
pending.
The API works in a similar way to g_application_hold and
g_application_release: applications can call g_application_mark_busy()
to increase a counter that will keep the application marked as busy
until the counter reaches zero again.
The busy state is exported read-only on the org.gtk.Application interface
for clients to use.
https://bugzilla.gnome.org/show_bug.cgi?id=672018
It is possible that the upstream servers return something, but
we then filter all results because they are of the wrong type.
In that case the API and subsequent GTask calls expect a GError
to be set.
https://bugzilla.gnome.org/show_bug.cgi?id=696857
to avoid warnings when built with -Wredundant-decls:
sessionmanager-presence-generated.c:316:1: warning: redundant redeclaration of ‘session_manager_presence_default_init’ [-Wredundant-decls]
sessionmanager-presence-generated.c:281:1: note: previous definition of ‘session_manager_presence_default_init’ was here
sessionmanager-presence-generated.c:1273:1: warning: redundant redeclaration of ‘object_default_init’ [-Wredundant-decls]
sessionmanager-presence-generated.c:1259:1: note: previous definition of ‘object_default_init’ was here
https://bugzilla.gnome.org/show_bug.cgi?id=696108
Expand and formalise the syntax for detailed action names, adding a
well-documented (and tested) public parser API for them.
Port the only GLib-based user of detailed action names to the new API:
g_menu_item_set_detailed_action(). The users in Gtk+ will also be
ported soon.
https://bugzilla.gnome.org/show_bug.cgi?id=688954
We need to close the stream *before* applying the file modes, because
g_file_replace() allocates a temporary file. At the moment we're
applying the modes to the extant file, then immediately rename()ing
over it with the default perms.
This regressed with commit 166766a89f.
The real fix here is to have g_file_create_with_info() so that we can
atomically create a file with the permissions we want.
https://bugzilla.gnome.org/show_bug.cgi?id=696014
_g_dbus_method_invocation_new is said to allow method_info == NULL,
but will crash inside g_dbus_method_info_ref when the method_info
really is NULL, because g_dbus_method_info_ref does not allow NULL as
parameter. Fixed by checking for NULL in _g_dbus_method_invocation_new
itself.
The leak itself happens because _g_dbus_method_invocation_new stores a
new reference to the method_info without also unreferencing it. Fixed
by adding the missing unref, protected by an if because the pointer
may be NULL.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=695376
We were using PATH_MAX to size a static array for reading lines from
the .hidden file. Some platforms (Hurd) don't declare a PATH_MAX.
Switch to using g_file_get_contents() and g_str_split('\n') instead.
Also take the time to clean up a bit with a switch to using a 'set mode'
GHashTable (since this code was originally written before we had those).
This patch is largely based on a patch from Emilio Pozuelo Monfort (who
also reported the bug).
https://bugzilla.gnome.org/show_bug.cgi?id=695147
Commit f641699 (for bug 675333) introduced a check whether the Exec= program in
a .desktop actually exists. This broke the /appinfo/mime/* test cases which use
executable names like "my_app".
Use real ones instead (like "echo" and "sleep"), and add a new
/appinfo/mime/ignore-nonexisting test case which verifies that
g_desktop_app_info_new() indeed ignores nonexisting executables.
https://bugzilla.gnome.org/show_bug.cgi?id=695191
Some (broken) toolchains for example trip up
-Werror=missing-prototypes in system headers. This patch allows
people to skip the formerly hardcoded "baseline" warnings.
https://bugzilla.gnome.org/show_bug.cgi?id=694757
The documentation was suggesting that using G_APPLICATION_IS_SERVICE
would automatically set an inactivity timeout (ie: app stays around for
a while after the use count drops to zero).
In reality, it only adds an initial 10 second wait for the first
activation message to arrive after which it uses the normal inactivity
timeout mechanism.
Implement the g_network_monitor_can_reach_async() rather than falling
back to the default implementation, which calls the sync version (not
in a thread).
https://bugzilla.gnome.org/show_bug.cgi?id=694181
Enumerate the GSocketConnectable before checking for a default route.
For some connectable types this will involve a DNS lookup. This will
elminate false positives for hosts behind a VPN since DNS lookup will
fail if the VPN is not connected.
https://bugzilla.gnome.org/show_bug.cgi?id=694181
If the resolver reloads (ie, if /etc/resolv.conf changes),
GNetworkAddress needs to re-resolve its addresses the next time it's
enumerated. Otherwise hosts that have different IP addresses inside
and outside a VPN won't work correctly if you hold on to a
GNetworkAddress for them for a long time.
https://bugzilla.gnome.org/show_bug.cgi?id=694181
If a GNetworkAddress is created with a hostname like "fe80::xxx%em1",
make sure that the scope_id corresponding to "em1" is present in the
GSocketAddresses it returns when used as a GSocketConnectable.
https://bugzilla.gnome.org/show_bug.cgi?id=684404
Add GSimpleProxyResolver, for letting people do static proxy
resolution, and to use as a base class for other resolvers (such as
GProxyResolverGnome).
https://bugzilla.gnome.org/show_bug.cgi?id=691105
Add a proxy-resolver property to GSocketClient, to allow overriding
proxy resolution in situations where you need to force a particular
proxy rather than using the system defaults.
https://bugzilla.gnome.org/show_bug.cgi?id=691105
This is a GLib reimplementation of dbus_address_escape_value().
It's useful if you want to construct a D-Bus address from pieces:
for instance, if you have a listening Unix socket whose path is known,
and you want to connect a D-Bus peer to it.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=693673
Reviewed-by: Colin Walters <walters@verbum.org>
[amended to add Since: 2.36 as per review]
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
If we don't connect to the control proxy's 'g-signal' signal, we won't have
'object-added' or 'object-removed' signals. So, connect to the 'g-signal' not
only when there already is a name-owner, but always.
https://bugzilla.gnome.org/show_bug.cgi?id=693285
While compiling, libtool will say that undefined symbols are not allowed, and
will refuse to make you a dll. This is only one line, easy to miss. And it
doesn't prevent `make' from completing successfully.
The code this patch adds is from other Makefile.am files that use
$(no_undefined). It's absence in gio is, most likely, an oversight.
Fixes#692058
The flowinfo and scope_id fields of struct sockaddr_in6 are in host
byte order, but the code previously assumed they were in network byte
order. Fix that.
This is an ABI-breaking change (since before you would have had to use
g_ntohl() and g_htonl() with them to get the correct values, and now
that would give the wrong values), but the previous behavior was
clearly wrong, and no one ever reported it, so it is likely that no
one was actually using it.
https://bugzilla.gnome.org/show_bug.cgi?id=684404
There are two benefits to this:
1) We can centralize any operating system specific knowledge of
close-vs-EINTR handling. For example, while on Linux we should never
retry, if someone cared enough later about HP-UX, they could come by
and change this one spot.
2) For places that do care about the return value and want to provide
the caller with a GError, this function makes it convenient to do so.
Note that gspawn.c had an incorrect EINTR loop-retry around close().
https://bugzilla.gnome.org/show_bug.cgi?id=682819
Ok, this function was just an awful mess before. Now the problem
domain is not trivial, and I won't claim this new code is *beautiful*,
but it should fix the bug at hand, and be somewhat less prone to
failure for the next person who tries to modify it. There's only one
unref call for each object now.
https://bugzilla.gnome.org/show_bug.cgi?id=692408
gio's glib-mkenums call needs to get gnetworking.h out of $(builddir),
not $(srcdir). Fix/simplify it by using $(filter) on $^ and letting
make find everything.
Also add -Wno-portability to AM_INIT_AUTOMAKE in configure.ac, so that
it doesn't warn about this (or about the gmake-specific features we
were already using in gio/tests/)
https://bugzilla.gnome.org/show_bug.cgi?id=691866
Use the same code GSocket does, to try SOCK_CLOEXEC first, and then
fall back to FD_CLOEXEC if it fails. (And fix that code to not call
fcntl if SOCK_CLOEXEC worked.)
https://bugzilla.gnome.org/show_bug.cgi?id=692332
When an error occurs while reading the file input stream in
g_file_load_contents (e.g. because the operation was cancelled), the
code is correctly calling g_task_return_error(), but in the callback
from the close operation, g_task_return_boolean() will be called again.
Code that cleans up its state in the async callback will then be called
twice, leading to invalid memory access.
https://bugzilla.gnome.org/show_bug.cgi?id=692202
Declare explicit support for monitor NFS from the fam file monitoring
backend. This will cause it to be preferred for monitoring on NFS, if
it is installed.
https://bugzilla.gnome.org/show_bug.cgi?id=592211
Add a pair of new extension points: 'gio-nfs-file-monitor' and
'gio-nfs-directory-monitor'.
Add a check to GLocalFile when creating a file monitor. If the
requested file is in the user's home directory and the user has an NFS
home directory then attempt to use an implementation of one of the new
extension points. If we don't have any implementations then fall back
to the normal "local" monitors.
https://bugzilla.gnome.org/show_bug.cgi?id=592211
Get rid of the complicated default module detection code in
GLocalFileMonitor and GLocalDirectoryMonitor and use the new
_gio_module_get_default_type() function instead.
This change also adds the ability to override the default file monitor
via the GIO_USE_FILE_MONITOR environment variable in the same way as can
be done for GIO_USE_VFS.
https://bugzilla.gnome.org/show_bug.cgi?id=592211
_gio_module_get_default() is a very convenient function for modules
implementing a singleton -- it finds the default module by priority
subject to override by a given environment variable name, instantiates
it, and caches the instance for future calls. It also has the ability
to query instances for being 'active' using a callback.
It doesn't work very well for non-singletons (like file monitors).
Add a new function _gio_module_get_default_type() that skips the
instantiation, returning the GType instead. As a replacement for the
'active' callback, a vtable offset can be given for a virtual function
to use to query if a particular backend is supported.
https://bugzilla.gnome.org/show_bug.cgi?id=592211
We have various sub directories in glib/ and gio/ (eg: inotify, gnulib,
pcre, xdgmime, etc.) that build convenience libraries that are then
included into libglib and libgio. The files in these directories need
to be built with the same visibility policy as the files in the first
level directories, so add CFLAGS for them all.
This wasn't a problem when the visibility flags were set directly in
CFLAGS but then we had to deal with some modules that we built that we
explicitly wanted to export symbols from.
For now, we can keep things the way they are because it's less hacky and
although it's a theoretical hazard to forget these CFLAGS, we rarely add
new subdirectories to the build.
Before this commit, the only difference between the expected and actual
ABI were the addition of _init and _fini symbols in each module (now
that regexp-based export control is not catching those).
Add read_async() and skip_async() tests to buffered-input-stream.
Fix and re-enable filter-streams's existing close_async() tests, and
add read_async(), skip_async(), and write_async() tests as well. Also,
redo the tests to use dummy GFilterInputStream and GFilterOutputStream
subclasses rather than GBufferedInput/OutputStream, so that we're
testing the base filter stream implementations of everything (since
the buffered stream overrides are already getting tested in the
buffered-input-stream and buffered-output-stream tests anyway).
Add a skip_async() test to unix-streams. (This one would crash without
the bugfix in the previous commit.)
skip_callback_wrapper expect the user_data (callback_data)
to be the task holding the task_data, not the task_data
itself.
Otherwise the task_data is cast as GTask and then task_data
is extracted from this bogus task.
https://bugzilla.gnome.org/show_bug.cgi?id=691812
We only want to control the default visibility for our five main
installable libraries: libglib, libgthread, libgmodule, libgobject,
libgio. We should therefore only set -fvisibility=hidden when building
those.
Use a separate substitution variable for this purpose.
Using CFLAGS directly leads to some modules built in testcases not
exporting their symbols (and then the tests fail). It also affects the
fam file monitoring module.
Colin had originally done it this way in his visibility patch series but
I failed to understand why so I didn't copy it. Now I do.
Also: revert changes made to two testcases in an attempt to work around
this issue.
https://bugzilla.gnome.org/show_bug.cgi?id=691756
Add an #ifdef G_OS_UNIX around the GLIB_AVAILABLE_IN_ALL annotation on
the _get_type() functions for GLocal{File,Directory}Monitor.
These symbols are in private header files and are only exported so that
the in-tree file monitoring modules can subclass. This is only needed
on UNIX and was therefore never part of the public ABI on Windows.
Caught by Dieter Verfaillie.
One of our testcases builds a small giomodule for testing the loading of
modules containing resources. Unfortunately, this module gets built
using the same CFLAGS as the rest of GLib, including the visibility
flags (defaulting to hidden).
Use "config.h" to get a declaration of _GLIB_EXTERN that will export
symbols properly and use it to annotate the necessary APIs.
The kqueue file monitoring backend was misusing G_GNUC_INTERNAL for want
of 'static' in a couple of places and also using it to declare a lock
that was never used at all.
Fix those up.
With visibility now under the control of __declspec(dllexport) we no
longer need to build .def files or use them for building our various
.dll files.
.def files used to be installed (even though it is only really useful
when creating the .dll or .lib file). Don't do that anymore either.
The Makefiles still contain rules to create a .lib file for use with
Visual Studio and these rules require .def files. There are special
requirements to using these rules (like having installed and setup
Microsoft tools for use during the build) and therefore the problem of
creating a .def file for use with them is left open to anyone willing to
make the effort. Many options are available depending on which
toolchain is in use (dlltool, pexport, gendef, dumpbin.exe, just to name
a few).
If we can find a free tool for creating .lib files in the future, we
should probably revisit this issue and add proper support back to our
build system.
Add the GLIB_AVAILABLE_IN_ALL annotation to all old functions (that
haven't already been annotated with the GLIB_AVAILABLE_IN_* macros or a
deprecation macro).
If we discover in the future that we cannot use only one macro on
Windows, it will be an easy sed patch to fix that.
https://bugzilla.gnome.org/show_bug.cgi?id=688681
glib-mkenums is not currently clever enough to know which version an
enum type was added in, so just mark all the _get_type() functions as
available in all versions.
https://bugzilla.gnome.org/show_bug.cgi?id=688681
This allows compilation with clang without errors, even when
-Wformat-nonliteral is active (as long as there are no real cases of
non literal formatting).
https://bugzilla.gnome.org/show_bug.cgi?id=691608
g_input_stream_real_skip_async() wants to use read_async() normally,
but will use skip() in a thread instead if it sees that read_async()
will end up using threads. Except that the test for "will read_async()
use threads" never got updated to know about the GPollableInputStream
support in read_async(), so it was doing the wrong thing in that case.
Fix.
Also remove a small bit of pre-GTask cruft noticed nearby.
https://bugzilla.gnome.org/show_bug.cgi?id=691489
For OSTree, I use Gio and also really care about performance. It's
disturbing to see open('.hidden') all over my straces and such. At
the moment I have an explicit set of things to query, as opposed to
"standard::*", since even before this that also implies an lstat() of
the parent directory.
This matches up with what we do for all the other attributes.
See https://bugzilla.gnome.org/show_bug.cgi?id=587806https://bugzilla.gnome.org/show_bug.cgi?id=691558
Since we're dynamically loading objects, after the g_type_init()
change, we now need to ensure people building with --as-needed don't
lose the DT_NEEDED on libgobject.
https://bugzilla.gnome.org/show_bug.cgi?id=691077
Some OS (e.g. OpenBSD) do not implement IP v4-mapped addresses. When
this is the case, then we get a "Connection refused", so force the test
to pass to that further tests can run.
https://bugzilla.gnome.org/show_bug.cgi?id=686058
The attached patch adds support for the btrfs "clone" ioctl which
makes Copy-on-Write reflinks, resulting in cheap O(1) copies when
source/destination are on the same filesystem. The ioctl itself is
quite straightforward, and GNU coreutils has had support since 7.5
(--reflink=auto --sparse=auto).
The ioctl only operates on regular files and symlinks, and always
follows symlinks; checks have been added accordingly.
This patch would be very useful for everyone who uses btrfs
filesystems (Meego folks for instance). On systems that don't have
btrfs, or if the the source is not on a btrfs filesystem, the ioctl
returns EINVAL, and the fallback code is triggered. Hence this will
cause no problems for non-btrfs users.
https://bugzilla.gnome.org/show_bug.cgi?id=626497
a5876e5f made GMemoryInputStream subclassable, but accidentally broke
read_async() and skip_async() in the process. The immediately
following e7983495 fixed read_async() (and added a test for it), but
skip_async() accidentally got... skipped.
Fix it now and add a test for it.
Also, GMemoryInputStream's skip_async() was assuming that skip() could
never fail, which is true of its own implementation, but might not be
true of a subclass's, so do proper GError handling too.
This will let us drop the dbus-python dependency.
The C version does not 100% reproduce all the hash table
and array manipulation of the python version, but the tests
do not rely on it anyway.
This greatly simplifies the test since everything is now in a single
process and possible bugs / quirks in libdbus-1 will not interfere
with the tests. On the other hand, we no longer test interoperability
with libdbus-1. This is somewhat moot, however, since other tests that
involve a message bus (e.g. GTestDBus users which include most of the
GDBus test suite itself) will test this.
Also ensure that we don't pollute existing D-Bus keyrings for the
DBUS_COOKIE_SHA1 authentication method (e.g. files in the
~/.dbus-keyrings directory) by setting the environment variables
G_DBUS_COOKIE_SHA1_KEYRING_DIR and
G_DBUS_COOKIE_SHA1_KEYRING_DIR_IGNORE_PERMISSION.
All in all, this change avoids some thorny issues where the GDBus and
libdbus-1 implementations disagree on whether an item in the D-Bus
keyring is still valid (items have an age etc.). In reality, since the
DBUS_COOKIE_SHA1 authentication method is never used in production,
this is never hit in production. This bug was, however, frequently hit
if you just ran the test suite repeatedly for 15 minutes or so.
Also add TODO items to mention that we currently don't test corner
cases involving
- DBUS_COOKIE_SHA1 timeouts
- libdbus-1 interoperability
Signed-off-by: David Zeuthen <zeuthen@gmail.com>
This DTD wasn't syntactically correct, and didn't actually
describe keys correctly. This change makes it a bit too lax,
but at least it can be used now.
https://bugzilla.gnome.org/show_bug.cgi?id=690538
This returns a GInputStream corresponding to the stdin on the
commandline that caused this invocation.
The local case works on both UNIX (GUnixInputStream on stdin) and
Windows (GWin32InputStream on GetStdHandle(STD_INPUT_HANDLE)). The
remote case works only on UNIX (by fd passing over D-Bus).
https://bugzilla.gnome.org/show_bug.cgi?id=668210
Add a new GFileMonitorFlag: G_FILE_MONITOR_WATCH_HARD_LINKS. When set,
changes made to the file via another hard link will be detected.
Implement the new flag for the inotify backend.
https://bugzilla.gnome.org/show_bug.cgi?id=532815
As RFC 2292 points out, some platforms (e.g. Darwin 9.8.0) provide
CMSG_FIRSTHDR(msg) which just returns msg.msg_control without first
checking if msg.msg_controllen is non-zero. We need a workaround for
such platforms not to let g_socket_receive_message() segfault.
https://bugzilla.gnome.org/show_bug.cgi?id=690388
If tasks block waiting for other tasks to complete then the system can
end up starved for threads. Avoid this by bumping up max-threads in
that case.
This also reverts 7b1f8c58 and reverts max-threads for GTask's
GThreadPool back to 10.
https://bugzilla.gnome.org/show_bug.cgi?id=687223
On IPv6 sockets, set both the IPv4 and IPv6 versions of IP socket
options, in case the socket is (or might become) IPv4-wrapped. (But
ignore errors when setting the IPv4 version.)
Similarly, when joining or leaving a multicast group, pick the sockopt
to use based on the address family of the multicast address rather
than the address family of the socket.
https://bugzilla.gnome.org/show_bug.cgi?id=687092
Since Windows builds by Visual C++ do not make use of autotools during
its build process, we need to dist a pre-configured
gio/gnetworking.h(.win32) for such builds.
The vs9/vs10 (and therefore vs11) property sheets are updated as well
https://bugzilla.gnome.org/show_bug.cgi?id=690163
This is a new convenience method designed to simplify some use
cases of GFileEnumerator, by making it easy to get the next file
from a file enumerator.
https://bugzilla.gnome.org/show_bug.cgi?id=690083
Add g_socket_get_option() and g_socket_set_option(), wrapping
getsockopt/setsockopt for the case of integer-valued options. Update
code to use these instead of the underlying calls.
https://bugzilla.gnome.org/show_bug.cgi?id=623187
Install a public "gnetworking.h" header that can be used to include
the relevant OS-dependent networking headers. This does not really
abstract away unix-vs-windows however; error codes, in particular,
are incompatible.
gnetworkingprivate.h now contains just a few internal URI-related
functions
Also add a g_networking_init() function to gnetworking.h, which can be
used to explicitly initialize OS-level networking, rather than having
that happen as a side-effect of registering GInetAddress.
https://bugzilla.gnome.org/show_bug.cgi?id=623187
Since there is only one resolver implementation now, we can move the
resolver utility functions from gresolver.c into gthreadedresolver.c,
and remove the prototypes from gnetworkingprivate.h.
https://bugzilla.gnome.org/show_bug.cgi?id=623187
The G_OBJECT_WARN_INVALID_PROPERTY_ID() macro uses a local variable
named "_object"; work around this by using "object" as the variable we
pass in.
https://bugzilla.gnome.org/show_bug.cgi?id=689377
This makes sure not to ifdef _g_io_win32_get_module() out when glib is
built as a static lib, and also fixes it to work when DllMain isn't
available.
The implementation uses GetModuleHandleEx() which is only available on
Windows XP and later, so this commit effectively drops the Windows 2000
support in glib. Earlier commit 731b4699 already took care of defining
_WIN32_WINNT to support the Windows XP API.
https://bugzilla.gnome.org/show_bug.cgi?id=675516
Now that we're directly accessing the memory holding a message blob,
we can access strings directly while reading them. This speeds up
read_string significantly, since we no longer malloc/memcpy/free.
The three processes this test creates need to be executed
in order, and g_usleep was used to guarantee that.
However, under heavy load, that is not enough. Instead,
wait until the children start by making sure they have
written to stdout before proceeding any further.
https://bugzilla.gnome.org/show_bug.cgi?id=664627
GData*Streams incur significant overhead, and we do not need all of the
functionality that they provide, since we only ever read from/write to
memory when handling message blobs, so it is more performant to use a
simple structure.
https://bugzilla.gnome.org/show_bug.cgi?id=652650
... and g_content_type_get_generic_icon_name(). The new functions are
implemented for Win32 since commit dace477c, so we no longer need to
guard them with G_OS_UNIX.
Really, the memory output stream API is too warped around the model
where it's a fixed size buffer that you've already allocated. Even in
C, I find myself always wanting to use it to just accumulate data into
an arbitrary-sized buffer it allocates.
Unfortunately, it's also not usable from bindings because it's not
common to bind g_free() and g_realloc(), but if you just pass NULL, you
get the default of a fixed size, which is useless as per above.
I am going to use this from a gjs test case, and the GSubprocess test
cases also will use it.
https://bugzilla.gnome.org/show_bug.cgi?id=688931
