Provides access to the g_settings_get_range() functionality, converting
its return value to something that's reasonable for printing at the
console and potentially parseable. The format may change.
Bug #631264.
Prevent assertion messages from spewing forth and also ensure that we
exit with an error status in the event that the value was out of range.
Bug #631264.
Don't store the "none" value for flags into the compiled schema file.
"none" should never appear as a value -- no flags set is indicated by an
empty array.
Ensure that the strinfo is output in little-endian byte order on big
endian machines.
GSettings is now passing all of its tests on PowerPC.
Bug #630968 is closed.
GSettings relies on parts of the schema infromation remaining
unbyteswapped (the strinfo database, for example) while requiring other
parts to be in native order (the default value, constraints, etc.).
Lift the byteswapping into a place where we can do it selectively.
The test case was passing a guint16 to g_object_get() for a guint
property. That's invalid on all systems, although it works (more or
less) on little endian ones. On big endian it's a total no-go.
For GSettings.
Use the functionality introduced in the last commit to simplify our
notify dispatching and increase the safety of doing so (by ensuring that
the context is acquired in the current thread for the duration of the
dispatch).
This closes bugs #623400 and #629849.
Rewrite the GSettings tool.
Improvements/changes:
- simplify the code by performing common actions (like creating a
schema) in only one place instead of one per-command
- new features (list schemas, list keys, monitor multiple, etc)
- factor-out bash completion and implement in shellscript
- input validation: should never abort due to invalid inputs
Still to do:
- proper error checking for ranges/choices
- support for querying range/choice information
- bash completion support for enums
Closes bug #629289, possibly among others.
In its previous form, g_settings_list_schemas() was not useful as a tool
to prevent aborts due to using g_settings_new() with an invalid schema
name. This is because g_settings_list_scheams() also listed relocatable
schemas, and calling g_settings_new() for those would abort just the
same as if you called it for a non-existent schema.
Modify g_settings_list_schemas() so that it only returns schemas for
which it is safe to call g_settings_new(). Add another call for sake of
completeness: g_settings_list_relocatable_schemas().
Implement the second feature requested in the bug: silently ignore
override files that attempt to override schemas that are not currently
installed.
Also, support 'strictness' being optional for other errors when parsing
override files (ie: inability to open the file, unknown key name, parse
errors, out of range). We don't completely back out the file in this
case — as that is difficult with the current implementation — but just
ignore the override for the single key.
Implement the first of two features requested in the bug: when
encountering a broken .xml schema file, back out the changes in that
file and continue to parse other files.
This prevents a single broken .xml file from messing up GSettings for
everyone else.
Add a --strict option to get the old behaviour. Use this from the test
cases.
Move all the annotations over from gobject-introspection.
They will not be used directly by the introspection scanner for now,
instead they will be extracted by a script and updated manually
until introspection is properly integrated into the glib build
It doesn't really work right now because of a dbus-daemon(1) bug - see
the comment added in the TODO section of gdbusconnection.c. So revert
to old behavior. The downside is a lot of files in /tmp but right now
that's better than not being able to run tests in a loop.
Signed-off-by: David Zeuthen <davidz@redhat.com>
Without this fix, the ./gdbus-connection test case occasionally fails, see
https://bugzilla.gnome.org/show_bug.cgi?id=629945#c5
like this
/gdbus/connection/basic: OK
/gdbus/connection/life-cycle: **
ERROR:gdbus-connection.c:223:test_connection_life_cycle: assertion failed:
(!quit_mainloop_fired)
cleaning up bus with pid 21794
Aborted (core dumped)
because the callback didn't happen on the same thread as where we are
running the loop.
Signed-off-by: David Zeuthen <davidz@redhat.com>
Since we make message buses come and go, we need to ensure that the
singleton connection instance goes away before attempting to call
g_bus_get_sync() or similar.
Signed-off-by: David Zeuthen <davidz@redhat.com>
When under load, a one second timeout is just not enough. This can be
observed by e.g. restarting a CPU- and IO-intensive application like a
web browser with many tabs while running the test cases. Therefore,
bump the timeouts to 30 seconds.
Signed-off-by: David Zeuthen <davidz@redhat.com>
Turns out that GDBusWorker will issue callbacks (in its own thread)
even after g_dbus_worker_stop() has been called. This would rarely
happen (and unreffing a connection is even rarer) so only saw this bug
occasionally when running the gdbus-connection test case in a loop.
Fix up this issue by maintaining a set of GDBusConnection objects that
are currently "alive" and do nothing in the callbacks if the passed
user_data pointer is not in this set.
Also attempted to fix up a race condition with
_g_object_wait_for_single_ref_do() and its use of GObject toggle
references - for now, just resort to busy waiting, thereby
sidestepping the toggle reference mess altogether.
Signed-off-by: David Zeuthen <davidz@redhat.com>
It looks like the deserialisation function in GSocketControlMessage can
potentially leak a reference to the class structure of a
GSocketControlMessage subclass (although the particular code path is
probably never hit).
Clean up the code a bit.
Also, make sure that the GUnixCredentialsMessage type is registered
before attempting deserialisation.
Closes bug #629687.
==7269== 144 bytes in 6 blocks are definitely lost in loss record 1,282 of 1,325
==7269== at 0x4005BDC: malloc (vg_replace_malloc.c:195)
==7269== by 0x4056B74: g_malloc (gmem.c:164)
==7269== by 0x406EDB6: g_slice_alloc (gslice.c:842)
==7269== by 0x406EDFB: g_slice_alloc0 (gslice.c:854)
==7269== by 0x413C627: g_type_create_instance (gtype.c:1867)
==7269== by 0x412276A: g_object_constructor (gobject.c:1480)
==7269== by 0x4121E5D: g_object_newv (gobject.c:1264)
==7269== by 0x4121BD3: g_object_new (gobject.c:1176)
==7269== by 0x417CFB9: g_credentials_new (gcredentials.c:156)
==7269== by 0x41D9DBC: g_unix_credentials_message_deserialize (gunixcredentialsmessage.c:149)
==7269== by 0x41C422C: g_socket_control_message_deserialize (gsocketcontrolmessage.c:198)
==7269== by 0x41BFCE3: g_socket_receive_message (gsocket.c:3289)
==7269== by 0x41D99CE: g_unix_connection_receive_credentials (gunixconnection.c:476)
==7269== by 0x41FA829: _g_dbus_auth_run_server (gdbusauth.c:987)
==7269== by 0x4205DDB: initable_init (gdbusconnection.c:2196)
Bug #629689.
These functions are meant to replace the read_until() flavour, with the
following improvements:
- consistency between the synchronous and asynchronous versions as to
if the separator character is read (it never is).
- support for using a nul byte as a separator character by way of
addition of a length parameter which allows stop_chars to be treated
as a byte array rather than a nul-terminated string.
The read_until() functions are not yet formally deprecated, but a note
has been added to the documentation warning not to use them as they will
be in the future.
This is bug #584284.
GSettings internally assumed that a change in key writability implied a
change in value. That may be true for some backends. Let those
backends deal with the situation for themselves.
The root problem is with GObject - for now, just work around it in
GDBus. Also include a test-case. See
https://bugzilla.gnome.org/show_bug.cgi?id=627724
for more information.
Signed-off-by: David Zeuthen <davidz@redhat.com>
