Darwin's poll doesn't change revents if there are no available events, though it returns 0. Initialize the fd.revents to 0 so that the test passes.
That reveals a test failure, though, because with socket streams it takes time for an event to pass through the socket. Provide an 80-usec delay to allow time for the propagation.
Add some extra protection when 'preparing' a group that doesn't yet
contain any menus. This can happen if you subscribe to a group that
doesn't yet exist.
It was possible to crash any application using
g_dbus_connection_export_menu_model() by requesting a non-existent
subscription group over the bus.
In practice this only happened in races -- where the proxy sees a group
that exists and queries it, but by the time it does, it's already gone.
https://bugzilla.gnome.org/show_bug.cgi?id=687089
GBusNameVanishedCallback is called with a NULL GDBusConnection in the
case that the connection has vanished. We were doing an assert to
verify that it was the same as we had exported the menu on and that
assert was failing.
https://bugzilla.gnome.org/show_bug.cgi?id=685995
g_socket_connection_connect_finish() was returning TRUE when the
connection attempt got cancelled. Fix that by using
g_simple_async_result_set_check_cancellable(). (Git master doesn't
have the bug because GTask behaves that way by default.)
https://bugzilla.gnome.org/show_bug.cgi?id=686213
We were using the user-passed value of the @property argument for
several purposes in g_settings_bind(): error messages, binding
uniqueness (ie: one-binding-per-property-per-object) and most
importantly, connecting to the detailed notify:: signal.
The user may pass a string like "property_name" when the property's
canonical name is "property-name". g_object_class_find_property() will
find the property under these circumstances, but a connection to
"notify::property_name" will not notice notifies emitted for
"property-name".
We can solve this by using the user's string to perform the lookup and
then using pspec->name for everything after that.
https://bugzilla.gnome.org/show_bug.cgi?id=684882
This is the expected (and sane) behavior - without this bug-fix you'd
have to add "Since" to every member of a newly added D-Bus interface.
Also show-case this in the codegen example.
Signed-off-by: David Zeuthen <zeuthen@gmail.com>
The newly-introduced functions, g_content_type_get_symbolic_icon() and
g_content_type_get_generic_icon_name() don't seem to be for Windows, at
least for now. So filter them out from gio.symbols on Windows.
Also, glocalfileinfo.c calls g_content_type_get_symbolic_icon() in
get_icon(), so only build that code when on Unix, for the time being.
https://bugzilla.gnome.org/show_bug.cgi?id=684278
Adding the --sourcedir option fixes these:
/path/to/src/gio/tests/test2.gresource.xml: Error on line 5 char 1: Failed to locate 'test1.txt' in current directory.
/path/to/src/gio/tests/test3.gresource.xml: Error on line 5 char 1: Failed to locate 'test1.txt' in current directory.
/path/to/src/gio/tests/test4.gresource.xml: Error on line 5 char 1: Failed to locate 'test1.txt' in current directory.
/path/to/src/gio/tests/test.gresource.xml: Error on line 5 char 1: Failed to locate 'test1.txt' in current directory.
Some programs attempt to use libglib (or even libgio) when setuid.
For a long time, GTK+ simply aborted if launched in this
configuration, but we never had a real policy for GLib.
I'm not sure whether we should advertise such support. However, given
that there are real-world programs that do this currently, we can make
them safer with not too much effort.
Better to fix a problem caused by an interaction between two
components in *both* places if possible.
This patch adds a private function g_check_setuid() which is used to
first ensure we don't run an external dbus-launch binary if
DBUS_SESSION_BUS_ADDRESS isn't set.
Second, we also ensure the local VFS is used in this case. The
gdaemonvfs extension point will end up talking to the session bus
which is typically undesirable in a setuid context.
Implementing g_check_setuid() is interesting - whether or not we're
running in a privilege-escalated path is operating system specific.
Note that GTK+'s code to check euid versus uid worked historically on
Unix, more modern systems have filesystem capabilities and SELinux
domain transitions, neither of which are captured by the uid
comparison.
On Linux/glibc, the way this works is that the kernel sets an
AT_SECURE flag in the ELF auxiliary vector, and glibc looks for it on
startup. If found, then glibc sets a public-but-undocumented
__libc_enable_secure variable which we can use. Unfortunately, while
it *previously* worked to check this variable, a combination of newer
binutils and RPM break it:
http://www.openwall.com/lists/owl-dev/2012/08/14/1
So for now on Linux/glibc, we fall back to the historical Unix version
until we get glibc fixed.
On some BSD variants, there is a issetugid() function. On other Unix
variants, we fall back to what GTK+ has been doing.
Reported-By: Sebastian Krahmer <krahmer@suse.de>
Signed-off-by: Colin Walters <walters@verbum.org>
g_dbus_connection_call_with_unix_fd_list_sync () and
g_dbus_connection_call_sync () should allow None for the
bus_name parameter.
https://bugzilla.gnome.org/show_bug.cgi?id=683771
Signed-off-by: Richard Hughes <richard@hughsie.com>
This reverts commit 4e7031f073db2df7297feab35c9d353b0b3977d8.
The string actually does get freed somewhere else, at least in some
cases. Can be looked at again later if this reintroduces a leak.
https://bugzilla.gnome.org/show_bug.cgi?id=683270
The test was assuming that all cancelled ops would finish within a
certain amount of time, but this often failed under valgrind. Instead,
just run the loop until all of the ops have actually finished.
https://bugzilla.gnome.org/show_bug.cgi?id=682560
If the interface given cannot be matched, `iface_obj' was left uninitialized and
the iface_obj == None check would end up crashing:
Traceback (most recent call last):
File "/usr/bin/gdbus-codegen", line 41, in <module>
sys.exit(codegen_main.codegen_main())
File "/usr/lib64/gdbus-2.0/codegen/codegen_main.py", line 175, in codegen_main
apply_annotations(all_ifaces, opts.annotate)
File "/usr/lib64/gdbus-2.0/codegen/codegen_main.py", line 146, in apply_annotations
apply_annotation(iface_list, iface, None, None, None, None, key, value)
File "/usr/lib64/gdbus-2.0/codegen/codegen_main.py", line 64, in apply_annotation
if iface_obj == None:
UnboundLocalError: local variable 'iface_obj' referenced before assignment
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=683088
On slower platforms, the overhead of the 240 D-BUS Sleep calls is larger than
the current maximum of 6 seconds. A run on a Panda board sometimes fails with
ERROR:/build/buildd/glib2.0-2.33.8/./gio/tests/gdbus-threading.c:409:test_method_calls_on_proxy:
assertion failed (elapsed_msec < 6000): (7365 < 6000)
Bump maximum time to 8 seconds to be more resilient to this.
https://bugzilla.gnome.org/show_bug.cgi?id=682222
Because it now handles EINTR. And we should do so. While most people
use Linux, which tries very hard to avoid propagating EINTR back up
into userspace, it can still happen.
https://bugzilla.gnome.org/show_bug.cgi?id=682833
