Otherwise, attempting to create a GSocketConnection from the socket
will likely return the wrong type, since the protocol won't match any
of the registered subtypes.
Also add the start of a GSocket test program (from davidz).
https://bugzilla.gnome.org/show_bug.cgi?id=627171
Makes explicit the fact that you are interacting with the individual
action rather than the group and removes potential namespace conflicts
with classes implementing the interface (like g_application_activate()
vs g_application_activate_action()).
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.
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 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.
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>
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.
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>
Ryan pointed out that it's safe to do this because we have the
G_DBUS_SEND_MESSAGE_FLAGS_PRESERVE_SERIAL flag and that it simplifies
how filter functions work.
Signed-off-by: David Zeuthen <davidz@redhat.com>
Otherwise things probably won't work in a garbage-collected world
(consider the trivial GC that never collects garbage).
This commit breaks GDBusServer ABI. No known released software is
using this code.
Signed-off-by: David Zeuthen <davidz@redhat.com>
Rework filter functions as per
https://bugzilla.gnome.org/show_bug.cgi?id=624546#c8
This commit breaks ABI. However, this ABI break affects only
applications using filter functions. The only known user of is dconf.
Signed-off-by: David Zeuthen <davidz@redhat.com>
Don't actually use this yet as that will require a couple of
modifications to the filter function signature. This is part of the
bug-fix for
https://bugzilla.gnome.org/show_bug.cgi?id=624546#c8
Signed-off-by: David Zeuthen <davidz@redhat.com>
==23341== 65 bytes in 3 blocks are definitely lost in loss record 927 of 1,020
==23341== at 0x4005BDC: malloc (vg_replace_malloc.c:195)
==23341== by 0x4057094: g_malloc (gmem.c:134)
==23341== by 0x40573DB: g_malloc_n (gmem.c:281)
==23341== by 0x40717FC: g_strdup (gstrfuncs.c:101)
==23341== by 0x4147F56: value_lcopy_string (gvaluetypes.c:313)
==23341== by 0x4123F0B: g_object_get_valist (gobject.c:1643)
==23341== by 0x41240FF: g_object_get (gobject.c:1731)
==23341== by 0x804C39E: test_basic (gdbus-proxy.c:522)
Bug #628331.
==23341== 85 (24 direct, 61 indirect) bytes in 1 blocks are definitely lost in loss record 900 of 971
==23341== at 0x4005BDC: malloc (vg_replace_malloc.c:195)
==23341== by 0x4057094: g_malloc (gmem.c:134)
==23341== by 0x406F2D6: g_slice_alloc (gslice.c:836)
==23341== by 0x406F31B: g_slice_alloc0 (gslice.c:848)
==23341== by 0x403A751: g_error_new_valist (gerror.c:54)
==23341== by 0x403AAD4: g_set_error (gerror.c:240)
==23341== by 0x420B807: decode_method_reply (gdbusconnection.c:4774)
==23341== by 0x420C2BA: g_dbus_connection_call_sync (gdbusconnection.c:5188)
==23341== by 0x421B7C9: g_dbus_proxy_call_sync (gdbusproxy.c:2477)
==23341== by 0x804BD89: test_bogus_method_return (gdbus-proxy.c:430)
Bug #628331.
==29535== 56 (24 direct, 32 indirect) bytes in 1 blocks are definitely lost in loss record 1,112 of 1,264
==29535== at 0x4005BDC: malloc (vg_replace_malloc.c:195)
==29535== by 0x4057094: g_malloc (gmem.c:134)
==29535== by 0x406F2D6: g_slice_alloc (gslice.c:836)
==29535== by 0x406F364: g_slice_copy (gslice.c:858)
==29535== by 0x403A9B2: g_error_copy (gerror.c:160)
==29535== by 0x42066D3: initable_init (gdbusconnection.c:2314)
==29535== by 0x41A73E5: g_initable_init (ginitable.c:105)
==29535== by 0x41A7587: g_initable_new_valist (ginitable.c:218)
==29535== by 0x41A742A: g_initable_new (ginitable.c:138)
==29535== by 0x4206DCC: g_dbus_connection_new_for_address_sync (gdbusconnection.c:2585)
==29535== by 0x804D63A: test_nonce_tcp (gdbus-peer.c:1229)
==29535== 107 (24 direct, 83 indirect) bytes in 1 blocks are definitely lost in loss record 1,188 of 1,264
==29535== at 0x4005BDC: malloc (vg_replace_malloc.c:195)
==29535== by 0x4057094: g_malloc (gmem.c:134)
==29535== by 0x406F2D6: g_slice_alloc (gslice.c:836)
==29535== by 0x406F364: g_slice_copy (gslice.c:858)
==29535== by 0x403A9B2: g_error_copy (gerror.c:160)
==29535== by 0x42066D3: initable_init (gdbusconnection.c:2314)
==29535== by 0x41A73E5: g_initable_init (ginitable.c:105)
==29535== by 0x41A7587: g_initable_new_valist (ginitable.c:218)
==29535== by 0x41A742A: g_initable_new (ginitable.c:138)
==29535== by 0x4206DCC: g_dbus_connection_new_for_address_sync (gdbusconnection.c:2585)
==29535== by 0x804D8E8: test_nonce_tcp (gdbus-peer.c:1259)
==29535== 112 (24 direct, 88 indirect) bytes in 1 blocks are definitely lost in loss record 1,193 of 1,264
==29535== at 0x4005BDC: malloc (vg_replace_malloc.c:195)
==29535== by 0x4057094: g_malloc (gmem.c:134)
==29535== by 0x406F2D6: g_slice_alloc (gslice.c:836)
==29535== by 0x406F364: g_slice_copy (gslice.c:858)
==29535== by 0x403A9B2: g_error_copy (gerror.c:160)
==29535== by 0x42066D3: initable_init (gdbusconnection.c:2314)
==29535== by 0x41A73E5: g_initable_init (ginitable.c:105)
==29535== by 0x41A7587: g_initable_new_valist (ginitable.c:218)
==29535== by 0x41A742A: g_initable_new (ginitable.c:138)
==29535== by 0x4206DCC: g_dbus_connection_new_for_address_sync (gdbusconnection.c:2585)
==29535== by 0x804D79A: test_nonce_tcp (gdbus-peer.c:1248)
==29535== 73 (24 direct, 49 indirect) bytes in 1 blocks are definitely lost in loss record 1,152 of 1,264
==29535== at 0x4005BDC: malloc (vg_replace_malloc.c:195)
==29535== by 0x4057094: g_malloc (gmem.c:134)
==29535== by 0x406F2D6: g_slice_alloc (gslice.c:836)
==29535== by 0x406F364: g_slice_copy (gslice.c:858)
==29535== by 0x403A9B2: g_error_copy (gerror.c:160)
==29535== by 0x42066D3: initable_init (gdbusconnection.c:2314)
==29535== by 0x41A73E5: g_initable_init (ginitable.c:105)
==29535== by 0x41A7587: g_initable_new_valist (ginitable.c:218)
==29535== by 0x41A742A: g_initable_new (ginitable.c:138)
==29535== by 0x4206DCC: g_dbus_connection_new_for_address_sync (gdbusconnection.c:2585)
==29535== by 0x804C6CE: test_peer (gdbus-peer.c:803)
Bug #628331.
==6793== 32 (24 direct, 8 indirect) bytes in 1 blocks are definitely lost in loss record 779 of 1,423
==6793== at 0x4005BDC: malloc (vg_replace_malloc.c:195)
==6793== by 0x4057094: g_malloc (gmem.c:134)
==6793== by 0x406F2D6: g_slice_alloc (gslice.c:836)
==6793== by 0x406F31B: g_slice_alloc0 (gslice.c:848)
==6793== by 0x413D5BB: g_type_create_instance (gtype.c:1867)
==6793== by 0x412372A: g_object_constructor (gobject.c:1482)
==6793== by 0x4122E1D: g_object_newv (gobject.c:1266)
==6793== by 0x4122B93: g_object_new (gobject.c:1178)
==6793== by 0x41DB4F9: g_unix_fd_list_new (gunixfdlist.c:159)
==6793== by 0x804AADD: test_interface_method_call (gdbus-peer.c:172)
Bug #628331.
==4616== 46 (32 direct, 14 indirect) bytes in 1 blocks are definitely lost in loss record 193 of 305
==4616== at 0x4005BDC: malloc (vg_replace_malloc.c:195)
==4616== by 0x4057094: g_malloc (gmem.c:134)
==4616== by 0x406F2D6: g_slice_alloc (gslice.c:836)
==4616== by 0x406F31B: g_slice_alloc0 (gslice.c:848)
==4616== by 0x413D5BB: g_type_create_instance (gtype.c:1867)
==4616== by 0x412372A: g_object_constructor (gobject.c:1482)
==4616== by 0x4123147: g_object_newv (gobject.c:1347)
==4616== by 0x41236BB: g_object_new_valist (gobject.c:1463)
==4616== by 0x4122BB4: g_object_new (gobject.c:1181)
==4616== by 0x41B2D0F: g_network_address_new (gnetworkaddress.c:262)
==4616== by 0x8048A70: test_basic (network-address.c:10)
Bug #628331.
==14059== 96 bytes in 2 blocks are definitely lost in loss record 520 of 543
==14059== at 0x4005BDC: malloc (vg_replace_malloc.c:195)
==14059== by 0x4057094: g_malloc (gmem.c:134)
==14059== by 0x406F2D6: g_slice_alloc (gslice.c:836)
==14059== by 0x406F31B: g_slice_alloc0 (gslice.c:848)
==14059== by 0x41385BB: g_type_create_instance (gtype.c:1867)
==14059== by 0x411E72A: g_object_constructor (gobject.c:1482)
==14059== by 0x411DE1D: g_object_newv (gobject.c:1266)
==14059== by 0x411DB93: g_object_new (gobject.c:1178)
==14059== by 0x42296AF: _g_local_file_input_stream_new (glocalfileinputstream.c:152)
==14059== by 0x422281F: g_local_file_read (glocalfile.c:1322)
==14059== by 0x418A8A9: open_read_async_thread (gfile.c:5050)
==14059== by 0x41B71BB: run_in_thread (gsimpleasyncresult.c:853)
==14059== by 0x41A5FBC: io_job_thread (gioscheduler.c:181)
==14059== by 0x407DCDE: g_thread_pool_thread_proxy (gthreadpool.c:314)
==14059== by 0x407C6B0: g_thread_create_proxy (gthread.c:1897)
==14059== by 0x57D918: start_thread (pthread_create.c:301)
==14059== by 0x4C6CBD: clone (clone.S:133)
Bug #628331.
==2464== 80 (16 direct, 64 indirect) bytes in 1 blocks are definitely lost in loss record 515 of 547
==2464== at 0x4005BDC: malloc (vg_replace_malloc.c:195)
==2464== by 0x4057094: g_malloc (gmem.c:134)
==2464== by 0x406F2D6: g_slice_alloc (gslice.c:836)
==2464== by 0x406F31B: g_slice_alloc0 (gslice.c:848)
==2464== by 0x41385BB: g_type_create_instance (gtype.c:1867)
==2464== by 0x411E72A: g_object_constructor (gobject.c:1482)
==2464== by 0x411DE1D: g_object_newv (gobject.c:1266)
==2464== by 0x411DB93: g_object_new (gobject.c:1178)
==2464== by 0x4220D74: _g_local_file_new (glocalfile.c:310)
==2464== by 0x422C897: g_local_vfs_get_file_for_path (glocalvfs.c:84)
==2464== by 0x41CA91C: g_vfs_get_file_for_path (gvfs.c:94)
==2464== by 0x418C1B6: g_file_new_for_path (gfile.c:5898)
==2464== by 0x8049509: test1_thread (contexts.c:110)
==2464== 80 (16 direct, 64 indirect) bytes in 1 blocks are definitely lost in loss record 516 of 547
==2464== at 0x4005BDC: malloc (vg_replace_malloc.c:195)
==2464== by 0x4057094: g_malloc (gmem.c:134)
==2464== by 0x406F2D6: g_slice_alloc (gslice.c:836)
==2464== by 0x406F31B: g_slice_alloc0 (gslice.c:848)
==2464== by 0x41385BB: g_type_create_instance (gtype.c:1867)
==2464== by 0x411E72A: g_object_constructor (gobject.c:1482)
==2464== by 0x411DE1D: g_object_newv (gobject.c:1266)
==2464== by 0x411DB93: g_object_new (gobject.c:1178)
==2464== by 0x4220D74: _g_local_file_new (glocalfile.c:310)
==2464== by 0x422C897: g_local_vfs_get_file_for_path (glocalvfs.c:84)
==2464== by 0x41CA91C: g_vfs_get_file_for_path (gvfs.c:94)
==2464== by 0x418C1B6: g_file_new_for_path (gfile.c:5898)
==2464== by 0x804964D: test_context_independence (contexts.c:144)
Bug #628331.
==2429== 49 (24 direct, 25 indirect) bytes in 1 blocks are definitely lost in loss record 276 of 355
==2429== at 0x4005BDC: malloc (vg_replace_malloc.c:195)
==2429== by 0x4057094: g_malloc (gmem.c:134)
==2429== by 0x406F2D6: g_slice_alloc (gslice.c:836)
==2429== by 0x406F31B: g_slice_alloc0 (gslice.c:848)
==2429== by 0x403A8A6: g_error_new_literal (gerror.c:117)
==2429== by 0x403AC31: g_set_error_literal (gerror.c:314)
==2429== by 0x4175525: g_buffered_input_stream_read_byte (gbufferedinputstream.c:880)
==2429== by 0x804A21A: test_read_byte (buffered-input-stream.c:153)
Bug #628331.
==2428== 256 bytes in 1 blocks are definitely lost in loss record 591 of 604
==2428== at 0x4005CD2: realloc (vg_replace_malloc.c:476)
==2428== by 0x40571A5: g_realloc (gmem.c:181)
==2428== by 0x4075287: g_string_maybe_expand (gstring.c:395)
==2428== by 0x40760D8: g_string_insert_c (gstring.c:1049)
==2428== by 0x4074D41: g_string_append_c_inline (gstring.h:153)
==2428== by 0x4075B3C: g_string_append_uri_escaped (gstring.c:822)
==2428== by 0x41A46AC: g_icon_to_string_tokenized (gicon.c:164)
==2428== by 0x41A498F: g_icon_to_string (gicon.c:252)
==2428== by 0x8049E1A: test_g_icon_serialize (g-icon.c:222)
Bug #628331.
==12763== 16,777,215 bytes in 1 blocks are possibly lost in loss record 357 of 357
==12763== at 0x4004F1B: calloc (vg_replace_malloc.c:418)
==12763== by 0x405711D: g_malloc0 (gmem.c:157)
==12763== by 0x8048ED6: test_basic (data-output-stream.c:40)
Bug #628331.
==2426== 45,034 bytes in 4,094 blocks are definitely lost in loss record 358 of 361
==2426== at 0x4005BDC: malloc (vg_replace_malloc.c:195)
==2426== by 0x4057094: g_malloc (gmem.c:134)
==2426== by 0x40573DB: g_malloc_n (gmem.c:281)
==2426== by 0x4071ABD: g_strconcat (gstrfuncs.c:315)
==2426== by 0x804916A: test_read_lines (data-output-stream.c:83)
Bug #628331.
