The GSocket docs point out that g_socket_send/g_socket_receive may
return G_IO_ERROR_WOULD_BLOCK even if g_socket_condition_check claimed
that they wouldn't. Fix the socket streams to check for that.
https://bugzilla.gnome.org/show_bug.cgi?id=603309
Add lots of padding for public class structures. Notably, we seemed to
lack any padding whatsoever in the GDBusMessageClass struct (spotted
by Dan Winship). Also switch to using
gpointer padding[N];
instead of
void (*_g_reserved1) (void);
...
void (*_g_reservedN) (void);
Signed-off-by: David Zeuthen <davidz@redhat.com>
This patch breaks some rarely-used public API (only known user is
dconf).
This patch is based on work from Peng Huang <shawn.p.huang@gmail.com>.
See https://bugzilla.gnome.org/show_bug.cgi?id=621945
Signed-off-by: David Zeuthen <davidz@redhat.com>
This is a minimal patch-out of the galias functionality. We will do a
release like this so that we can easily back it out if there are
reported problems.
A more substantial cleanup (mostly removing #includes from every file)
will follow if there are no issues.
Having this tool in GLib is a bad idea for a number of reasons:
- experience has shown that the simple file format was a bad idea
- the tool is currently implemented with a hack that would require a
dependency inversion to solve (the tool needs to depend on Python
GVariant bindings)
- the tool itself is unmaintained
It will be moved to the GConf git repository so people can continue to
use it for the purpose of converting GConf schemas.
When no path is provided for the schema, we have call
g_settings_new() instead of g_settings_new_with_path()
passing a NULL path.
This was crashing the tool on start since an assertion was
recently added to g_settings_new_with_path() to refuse NULL.
We can't search for a larger needle inside of a smaller haystack, and
unsigned integer subtraction tends to result in very large numbers
rather than small ones.
Add a check for this case and abort out immediately.
Also add a test case (lifted directly from the docs) that demonstrates
the problem.
Issue discovered and tracked down by Milan Bouchet-Valat
See https://bugzilla.gnome.org/show_bug.cgi?id=621838 for the whole
story. The problem was that we ended up reading data from arrays of
arrays when we were just supposed to be aligning the buffers.
Also add a host of debug infrastructure that was needed to find the
root cause. For now it can be turned on only via defining
DEBUG_SERIALIZER. In the future we might want to make it work via
G_DBUS_DEBUG. In a nutshell, the added debug info looks like this
Parsing blob (blob_len = 0x0084 bytes)
0000: 6c 01 00 01 3c 00 00 00 41 00 00 00 37 00 00 00 l...<...A...7...
0010: 08 01 67 00 08 61 61 79 61 7b 73 76 7d 00 00 00 ..g..aaya{sv}...
0020: 01 01 6f 00 08 00 00 00 2f 66 6f 6f 2f 62 61 72 ..o...../foo/bar
0030: 00 00 00 00 00 00 00 00 03 01 73 00 06 00 00 00 ..........s.....
0040: 4d 65 6d 62 65 72 00 00 00 00 00 00 34 00 00 00 Member......4...
0050: 03 00 00 00 63 77 64 00 01 73 00 00 23 00 00 00 ....cwd..s..#...
0060: 2f 68 6f 6d 65 2f 64 61 76 69 64 7a 2f 48 61 63 /home/davidz/Hac
0070: 6b 69 6e 67 2f 67 6c 69 62 2f 67 69 6f 2f 74 65 king/glib/gio/te
0080: 73 74 73 00 sts.
Parsing headers (blob_len = 0x0084 bytes)
Reading type a{yv} from offset 0x000c: array spans 0x0037 bytes
Reading type {yv} from offset 0x0010
Reading type y from offset 0x0010: 0x08 '
Reading type v from offset 0x0011
Reading type g from offset 0x0014: 'aaya{sv}'
Reading type {yv} from offset 0x001e
Reading type y from offset 0x0020: 0x01 ''
Reading type v from offset 0x0021
Reading type o from offset 0x0024: '/foo/bar'
Reading type {yv} from offset 0x0031
Reading type y from offset 0x0038: 0x03 ''
Reading type v from offset 0x0039
Reading type s from offset 0x003c: 'Member'
Parsing body (blob_len = 0x0084 bytes)
Reading type (aaya{sv}) from offset 0x0047
Reading type aay from offset 0x0048: array spans 0x0000 bytes
Reading type a{sv} from offset 0x004c: array spans 0x0034 bytes
Reading type {sv} from offset 0x0050
Reading type s from offset 0x0050: 'cwd'
Reading type v from offset 0x0058
Reading type s from offset 0x005b: '/home/davidz/Hacking/glib/gio/tests'
OK
Signed-off-by: David Zeuthen <davidz@redhat.com>
While we are already propagating the error to the user via the
GDBusConnection::disconnected signal (because the only safe thing is
to disconnect the other peer), changes are the user is simply not
listening to this signal.
This should never ever happen unless there's a bug in the
serializaer/deserializer so it's fine to complain via g_warning()
here.
Bug 621838, see
https://bugzilla.gnome.org/show_bug.cgi?id=621838
is related to this.
Signed-off-by: David Zeuthen <davidz@redhat.com>
The GType for a GVariant is now a fundamental GType instead of a boxed
one so use the right marshaller.
Signed-off-by: David Zeuthen <davidz@redhat.com>
When asynchronously acquiring the DBus connection, assume a reference to
the proxy object, to avoid destroying it in the middle of the operation.
See https://bugzilla.gnome.org/show_bug.cgi?id=621905
Like how we're handling activation, use GVariant for timestamps. To
avoid polluting the GtkApplication API with GVariants, we rename the
GApplication signals to "quit-with-data" and "action-with-data".
GtkApplication will then wrap those as just "quit" and "action".
https://bugzilla.gnome.org/show_bug.cgi?id=621002
Allow constructing a GDBusProxy for well-known names as discussed here
http://mail.gnome.org/archives/gtk-devel-list/2009-October/msg00075.html
including test cases.
Make it possible to create a GDBusProxy for a GBusType instead of a
GDBusConnection. This requires G_BUS_TYPE_NONE so add that too.
Nuke g_bus_watch_proxy() since one can now more or less use GDBusProxy
for this.
Port gdbus-example-watch-proxy to this new API and include this
example in the GDBusProxy doc page.
Also nuke the GType parameter from the GDBusProxy constructors as
requested here: https://bugzilla.gnome.org/show_bug.cgi?id=621229
Also update the porting guide and other API docs for this change.
Also fix a bug in the signal dispatching code so each subscriber only
get notified once, not N times, for the same signal. Also add a test
case for this.
https://bugzilla.gnome.org/show_bug.cgi?id=621213
Signed-off-by: David Zeuthen <davidz@redhat.com>
The name buffer_availabile was kinda confusing, so its been renamed
to buffer_data_size() to match buffer_data().
Also I added a comment to buffer_ensure_space because its behaviour
wasn't obvious.
When the converter fills the whole buffer without reading all input,
we need to enlarge the buffer. Otherwise we get an assertion failure
for `outbuf_size > 0' in g_converter_convert.
https://bugzilla.gnome.org/show_bug.cgi?id=619945
gvdb just dropped the ability to have a separate "options" field. We
now store the options into a GVariant along with the default value.
For now, we use a small shim in GSettingsSchema in order not to touch
too much code. A more complete rewrite will follow.
This represents a change to the schema file format with another likely
to follow. glib-compile-schemas needs to be re-run after installing
this change.
accept more than one callback.
g_bus_own_name_with_closures
g_bus_own_name_on_connection_with_closures
g_bus_watch_name_with_closures
g_bus_watch_name_on_connection_with_closures
g_bus_watch_proxy_with_closures
g_bus_watch_proxy_on_connection_with_closures
https://bugzilla.gnome.org/show_bug.cgi?id=621092
Create a function run_with_application that both ensures the
app is running exactly while the test is running, which most
of the tests use. We start it beforehand, and kill it after.
This avoids having any interdependence between the tests (and
there definitely was before, because we didn't wait for
the process to actually terminate after a kill() call).
Also, open a pipe between the two, and have the child app
monitor that pipe. If it gets closed (e.g. because the parent
died), the child exits. This is the most reliable way to
avoid stale children; before, if we failed an assertion, the
parent would abort, and not run kill().
https://bugzilla.gnome.org/show_bug.cgi?id=621034
There was a slight race where we ended up calling into user code if
the user managed to unregister an object (or subtree) in the window
between
- processing the remote call on the worker thread; and
- continuing handling it on the user code thread (via an idle handler)
This patch fixes the problem.
Signed-off-by: David Zeuthen <davidz@redhat.com>
Fix proxy construction for objects with no properties in the case
where G_DBUS_PROXY_FLAGS_DO_NOT_LOAD_PROPERTIES isn't set.
The unfortunate side-effect here is that GDBusProxy can no longer be
used to test for "object existence", e.g. creating a GDBusProxy for
any path and interface will not fail. But that's not really a big
deal, if apps rely on that they are doing something very wrong.
https://bugzilla.gnome.org/show_bug.cgi?id=621119
Signed-off-by: David Zeuthen <davidz@redhat.com>
This adds a GApplication object to GIO, which is the core of
an application support class, supporting
- uniqueness
- exporting actions (simple scripting)
- standard actions (quit, activate)
The implementation for Linux uses D-Bus, takes a name on the
session bus, and exports a org.gtk.Application interface.
Implementations for Win32 and OS X are still missing.
The GSettings schema compiler was accepting any string as a path. It is
probably quite a common mistake to suspect that '/apps/foo' is a valid
path name when this will cause all sorts of trouble later. Check for
this case and report the error.
Since #include <gsettingsbackend.h> is a perfectly valid thing for
applications to do, and since we want to include gio headers from
gsettingsbackend.h, we need to effectively disable the #error we would
get from those headers (because we're not coming via gio.h).
We don't want to #include <gio/gio.h> here because this would cause
needless rebuilding of GSettingsBackend, GSettings,
GDelayedSettingsBackend, etc... every time someone changed anything in
any public header.
add GSimplePermission, a trivial const implementation of GPermission
can-request and can-release are always false for this implementation and
the value of 'allowed' is decided at construction.
Add GObject introspection annotations so that the length parameter is
correctly detected for g_variant_new_strv(), g_variant_get_strv() and
g_variant_dup_strv(). Also specify that it can be a NULL pointer in
g_variant_get_strv() and g_variant_dup_strv().
For g_settings_set_strv(), detect that a NULL value is allowed, meaning
empty array.
Closes bug #620384.
Signed-off-by: Ryan Lortie <desrt@desrt.ca>
Length of the array is redundant since it's NULL-terminated. This is not
consistent with many GLib and GTK+ functions, and adds complexity with
no real gain, while these convenience functions should be kept simple.
Closes bug #620312
This allows the caller to specify the reply type that they are expecting
for this call. If the reply comes back with the wrong type, GDBus will
generate an appropriate error internally.
- add a GVariantType * argument to g_dbus_connection_call() and
_call_sync().
- move the internal API for computing message types from introspection
data to be based on GVariantType instead of strings. Update users
of this code.
- have GDBusProxy pass this calculated GVariantType into
g_dbus_connection_call(). Remove the checks done in GDBusProxy.
- Update other users of the code (test cases, gdbus-tool, GSettings
tool, etc). In some cases, remove redundant checks; in some other
cases, we are fixing bugs because no checking was done where it
should have been.
Closes bug #619391.
Ryan pointed out on IRC that we didn't do anything here. Looking at
the code, it's painfully obvious that we should be returning an error
here since a comment already says that we've exhausted all possible
options.
Signed-off-by: David Zeuthen <davidz@redhat.com>
- Fix various #include issues
- Change #error to #warning for the EXTERNAL authentication mechanism.
It is not clear if this should work on Win32 at all.
- Call close() before unlink() for the SHA1 keyring
- Change #error to #warning so we don't forget to do
permission checking of the .dbus-keyrings directory
- Use Win32 SID for the SHA1 auth mech
- Apparently we can't use word 'interface' as an identifier
- Implement a _g_dbus_win32_get_user_sid() function. For now it's
private. Don't know if it should be public somewhere. Maybe in
a future GCredentials support for Win32? I don't know.
- GFileDescriptorBased is not available on Win32. So avoid using
it in GLocalFile stuff. Now, Win32 still uses GLocalFile + friends
(which works with file descriptors) so expose a private function
to get the fd for an OutputStream so things still work.
- Fixup gio.symbols
- Fixup tests/gdbus-peer.c so it builds
With this, at least things compile and the gdbus-peer.exe test case
passes. Which is a great start. I've tested this by cross-compiling on
a x86_64 Fedora 13 host using mingw32 and running the code on a 32-bit
Windows 7 box.
https://bugzilla.gnome.org/show_bug.cgi?id=619142
Signed-off-by: David Zeuthen <davidz@redhat.com>
If --uninstall is given then don't give an error if the schema directory
is empty. Instead, erase the gschemas.compiled file, if it exists.
This is the right thing to do in the 'make uninstall' rule, where the
schema directory could very well be left empty as a result.
Modify gsettings.m4 to use this option.
The test was assuming that g_timeout_add() waited for at least the amount of
time given to it before running the function. This is not the case -- the
function can be run as much as 1ms early. Make the lower time bound asserted
in the test more permissive to account for this.
- hold a lock while accessing the tree of delayed values
- use weak reference counts with the owner object to avoid doing
g_object_notify on a dead object
- dispatch the "has-unapplied" notify to the proper main context
This commit fixes up a few race conditions in the GSettingsBackend, mostly with
respect to change notifications occuring at the same time as the last reference
count on a GSettings is dropped. With GDBus feeding us our incoming signals in
a separate thread, this is something that could easily happen.
There is currently no way (near as I can tell) to ensure that a message
has been sent when using GDBus. If we exit() before we are sure, then
it is very possible that the message isn't sent at all. This behaviour
was observed when using the GSettings commandline tool with dconf.
A quick and dirty workaround for now.
Don't define __USE_GNU, thats a glibc-internal macro, and
don't use SOL_SOCKET when not including sys/socket.h.
Maybe this file should be called glinuxcredentialsmessage.c...
Bug #618730
Rename the --schema-files option to --schema-file, since it only
accepts one file at a time. Change the GSETTINGS_CHECK_RULE to
use it that way, too. And also make it work better with !srcdir
builds.
Bugs #616731 and #616864
Without this fix, we segfault if the exported object returned an error
on all get_property() calls (in reality, this never happens).
Signed-off-by: David Zeuthen <davidz@redhat.com>
Fix an unintentional double free introduced in commit
4ad4c306c3.
This bug manifested itself when trying to complete this
$ gdbus introspect --system --dest <tab>
From valgrind running gdbus-peer test:
==20513== 32 bytes in 1 blocks are definitely lost in loss record 1 of 15
==20513== at 0x4024E4C: realloc (vg_replace_malloc.c:429)
==20513== by 0x4079BB1: g_realloc (gmem.c:174)
==20513== by 0x4099472: g_string_maybe_expand (gstring.c:396)
==20513== by 0x409A42A: g_string_insert_c (gstring.c:1050)
==20513== by 0x42169AC: g_string_append_c_inline (gstring.h:153)
==20513== by 0x421682C: _my_g_input_stream_read_line_safe (gdbusauth.c:336)
==20513== by 0x421843E: _g_dbus_auth_run_server (gdbusauth.c:1265)
==20513== by 0x4222B94: initable_init (gdbusconnection.c:1783)
==20513== by 0x41CF8D5: g_initable_init (ginitable.c:106)
==20513== by 0x41CFA8D: g_initable_new_valist (ginitable.c:219)
==20513== by 0x41CF920: g_initable_new (ginitable.c:139)
==20513== by 0x4223479: g_dbus_connection_new_sync (gdbusconnection.c:2046)
Bug #618650.
==6279== 21,615 (4,708 direct, 16,907 indirect) bytes in 169 blocks are
definitely lost in loss record 12 of 13
==6279== at 0x4024D2E: malloc (vg_replace_malloc.c:207)
==6279== by 0x4079A90: g_malloc (gmem.c:135)
==6279== by 0x4079DC8: g_malloc_n (gmem.c:252)
==6279== by 0x4097E66: g_strsplit (gstrfuncs.c:2434)
==6279== by 0x42169A2: g_dbus_address_get_stream_sync
(gdbusaddress.c:875)
Bug #618622.
Free the bus address after creating the singleton.
==26308== 39,736 (10,517 direct, 29,219 indirect) bytes in 388 blocks
are definitely lost in loss record 14 of 15
==26308== at 0x4024D2E: malloc (vg_replace_malloc.c:207)
==26308== by 0x4079A90: g_malloc (gmem.c:135)
==26308== by 0x4079DC8: g_malloc_n (gmem.c:252)
==26308== by 0x4095607: g_strdup (gstrfuncs.c:102)
==26308== by 0x4216B9A: g_dbus_address_get_for_bus_sync
(gdbusaddress.c:961)
==26308== by 0x422A7AE: get_uninitialized_connection
(gdbusconnection.c:5241)
Bug #618622.
