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.
==12351== 45,045 bytes in 4,095 blocks are definitely lost in loss record 377 of 380
==12351== at 0x4005BDC: malloc (vg_replace_malloc.c:195)
==12351== by 0x4057094: g_malloc (gmem.c:134)
==12351== by 0x40573DB: g_malloc_n (gmem.c:281)
==12351== by 0x4071ABD: g_strconcat (gstrfuncs.c:315)
==12351== by 0x8049811: test_read_lines (data-input-stream.c:99)
Bug #628331.
==2415== 45,045 bytes in 4,095 blocks are definitely lost in loss record 393 of 399
==2415== at 0x4005BDC: malloc (vg_replace_malloc.c:195)
==2415== by 0x4057094: g_malloc (gmem.c:134)
==2415== by 0x417FC29: g_data_input_stream_read_line (gdatainputstream.c:797)
==2415== by 0x8049874: test_read_lines (data-input-stream.c:111)
==12088== 360 bytes in 40 blocks are definitely lost in loss record 368 of 381
==12088== at 0x4005BDC: malloc (vg_replace_malloc.c:195)
==12088== by 0x4057094: g_malloc (gmem.c:134)
==12088== by 0x417FF4C: g_data_input_stream_read_until (gdatainputstream.c:914)
==12088== by 0x8049B6F: test_read_until (data-input-stream.c:182)
Bug #628331.
==2415== 165 (72 direct, 93 indirect) bytes in 3 blocks are definitely lost in loss record 373 of 399
==2415== at 0x4005BDC: malloc (vg_replace_malloc.c:195)
==2415== by 0x4057094: g_malloc (gmem.c:134)
==2415== by 0x406F2D6: g_slice_alloc (gslice.c:836)
==2415== by 0x406F31B: g_slice_alloc0 (gslice.c:848)
==2415== by 0x403A8A6: g_error_new_literal (gerror.c:117)
==2415== by 0x403AC31: g_set_error_literal (gerror.c:314)
==2415== by 0x417ED29: read_data (gdatainputstream.c:309)
==2415== by 0x417EE9D: g_data_input_stream_read_byte (gdatainputstream.c:344)
==2415== by 0x8049DEC: test_data_array (data-input-stream.c:263)
Bug #628331.
==10395== 80 (24 direct, 56 indirect) bytes in 1 blocks are definitely lost in loss record 529 of 561
==10395== at 0x4005BDC: malloc (vg_replace_malloc.c:195)
==10395== by 0x4057094: g_malloc (gmem.c:134)
==10395== by 0x406F2D6: g_slice_alloc (gslice.c:836)
==10395== by 0x406F31B: g_slice_alloc0 (gslice.c:848)
==10395== by 0x403A751: g_error_new_valist (gerror.c:54)
==10395== by 0x403AAD4: g_set_error (gerror.c:240)
==10395== by 0x4230328: _g_local_file_output_stream_create (glocalfileoutputstream.c:628)
==10395== by 0x4227A04: g_local_file_create_readwrite (glocalfile.c:1388)
==10395== by 0x418974C: g_file_create_readwrite (gfile.c:1784)
==10395== by 0x8049FCD: test_g_file_create_readwrite (readwrite.c:187)
Bug #628331.
==8564== 24,000,000 bytes in 6 blocks are possibly lost in loss record 592 of 594
==8564== at 0x4005BDC: malloc (vg_replace_malloc.c:195)
==8564== by 0x4057094: g_malloc (gmem.c:134)
==8564== by 0x804AA37: test_corruption (converter-stream.c:589)
==8564== by 0x804B05B: test_roundtrip (converter-stream.c:652)
==9459== 25,165,824 bytes in 6 blocks are possibly lost in loss record 593 of 594
==9459== at 0x4005CD2: realloc (vg_replace_malloc.c:476)
==9459== by 0x40571A5: g_realloc (gmem.c:181)
==9459== by 0x41B08A3: array_resize (gmemoryoutputstream.c:501)
==9459== by 0x41B0A5D: g_memory_output_stream_write (gmemoryoutputstream.c:578)
==9459== by 0x41B57EF: g_output_stream_write (goutputstream.c:216)
==9459== by 0x41B591B: g_output_stream_write_all (goutputstream.c:268)
==9459== by 0x417D617: flush_buffer (gconverteroutputstream.c:359)
==9459== by 0x417D958: g_converter_output_stream_write (gconverteroutputstream.c:502)
==9459== by 0x41B5D7F: g_output_stream_real_splice (goutputstream.c:428)
==9459== by 0x41B5C6C: g_output_stream_splice (goutputstream.c:380)
==9459== by 0x804AB10: test_corruption (converter-stream.c:600)
==9785== 25,165,824 bytes in 6 blocks are possibly lost in loss record 592 of 592
==9785== at 0x4005CD2: realloc (vg_replace_malloc.c:476)
==9785== by 0x40571A5: g_realloc (gmem.c:181)
==9785== by 0x41B08A3: array_resize (gmemoryoutputstream.c:501)
==9785== by 0x41B0A5D: g_memory_output_stream_write (gmemoryoutputstream.c:578)
==9785== by 0x41B5D7F: g_output_stream_real_splice (goutputstream.c:428)
==9785== by 0x41B5C6C: g_output_stream_splice (goutputstream.c:380)
==9785== by 0x804ADF1: test_corruption (converter-stream.c:622)
==9785== by 0x804B06C: test_roundtrip (converter-stream.c:652)
Bug #628331.
==7540== 487 (64 direct, 423 indirect) bytes in 2 blocks are definitely lost in loss record 597 of 615
==7540== at 0x4005BDC: malloc (vg_replace_malloc.c:195)
==7540== by 0x4057094: g_malloc (gmem.c:134)
==7540== by 0x406F2D6: g_slice_alloc (gslice.c:836)
==7540== by 0x406F31B: g_slice_alloc0 (gslice.c:848)
==7540== by 0x413D5BB: g_type_create_instance (gtype.c:1867)
==7540== by 0x412372A: g_object_constructor (gobject.c:1482)
==7540== by 0x4123147: g_object_newv (gobject.c:1347)
==7540== by 0x41236BB: g_object_new_valist (gobject.c:1463)
==7540== by 0x41A756E: g_initable_new_valist (ginitable.c:214)
==7540== by 0x41A743E: g_initable_new (ginitable.c:138)
==7540== by 0x417B67A: g_charset_converter_new (gcharsetconverter.c:215)
==7540== by 0x804B043: test_charset (converter-stream.c:675)
Bug #628331.
==2396== 168 (92 direct, 76 indirect) bytes in 1 blocks are definitely lost in loss record 598 of 625
==2396== at 0x4005BDC: malloc (vg_replace_malloc.c:195)
==2396== by 0x4057094: g_malloc (gmem.c:134)
==2396== by 0x406F2D6: g_slice_alloc (gslice.c:836)
==2396== by 0x406F31B: g_slice_alloc0 (gslice.c:848)
==2396== by 0x413D5BB: g_type_create_instance (gtype.c:1867)
==2396== by 0x412372A: g_object_constructor (gobject.c:1482)
==2396== by 0x4123147: g_object_newv (gobject.c:1347)
==2396== by 0x41236BB: g_object_new_valist (gobject.c:1463)
==2396== by 0x4122BB4: g_object_new (gobject.c:1181)
==2396== by 0x417C54D: g_converter_input_stream_new (gconverterinputstream.c:204)
==2396== by 0x804A53E: test_compressor (converter-stream.c:484)
Bug #628331.
==2396== 66 (24 direct, 42 indirect) bytes in 1 blocks are definitely lost in loss record 565 of 625
==2396== at 0x4005BDC: malloc (vg_replace_malloc.c:195)
==2396== by 0x4057094: g_malloc (gmem.c:134)
==2396== by 0x406F2D6: g_slice_alloc (gslice.c:836)
==2396== by 0x406F31B: g_slice_alloc0 (gslice.c:848)
==2396== by 0x403A8A6: g_error_new_literal (gerror.c:117)
==2396== by 0x403AC31: g_set_error_literal (gerror.c:314)
==2396== by 0x417BA38: g_charset_converter_convert (gcharsetconverter.c:344)
==2396== by 0x417BF67: g_converter_convert (gconverter.c:174)
==2396== by 0x417C9EB: g_converter_input_stream_read (gconverterinputstream.c:403)
==2396== by 0x41A7A17: g_input_stream_read (ginputstream.c:204)
==2396== by 0x41A7B43: g_input_stream_read_all (ginputstream.c:256)
==2396== by 0x804B0E4: test_charset (converter-stream.c:682)
Bug #628331.
==2396== 39 (24 direct, 15 indirect) bytes in 1 blocks are definitely lost in loss record 398 of 625
==2396== at 0x4005BDC: malloc (vg_replace_malloc.c:195)
==2396== by 0x4057094: g_malloc (gmem.c:134)
==2396== by 0x406F2D6: g_slice_alloc (gslice.c:836)
==2396== by 0x406F31B: g_slice_alloc0 (gslice.c:848)
==2396== by 0x403A8A6: g_error_new_literal (gerror.c:117)
==2396== by 0x403AC31: g_set_error_literal (gerror.c:314)
==2396== by 0x80498F7: g_compressor_converter_convert (converter-stream.c:244)
==2396== by 0x417BF67: g_converter_convert (gconverter.c:174)
==2396== by 0x417CBDE: g_converter_input_stream_read (gconverterinputstream.c:460)
==2396== by 0x41A7A17: g_input_stream_read (ginputstream.c:204)
==2396== by 0x804A832: test_compressor (converter-stream.c:545)
Bug #628331.
==2395== 64 bytes in 1 blocks are definitely lost in loss record 381 of 407
==2395== at 0x4005BDC: malloc (vg_replace_malloc.c:195)
==2395== by 0x4005C66: realloc (vg_replace_malloc.c:476)
==2395== by 0x40571A5: g_realloc (gmem.c:181)
==2395== by 0x401D670: g_ptr_array_maybe_expand (garray.c:968)
==2395== by 0x401DD0B: g_ptr_array_add (garray.c:1225)
==2395== by 0x4199AA9: g_file_info_list_attributes (gfileinfo.c:646)
==2395== by 0x80491CE: test_g_file_info (g-file-info.c:76)
==2395== 132 (64 direct, 68 indirect) bytes in 1 blocks are definitely lost in loss record 396 of 407
==2395== at 0x4005BDC: malloc (vg_replace_malloc.c:195)
==2395== by 0x4005C66: realloc (vg_replace_malloc.c:476)
==2395== by 0x40571A5: g_realloc (gmem.c:181)
==2395== by 0x401D670: g_ptr_array_maybe_expand (garray.c:968)
==2395== by 0x401DD0B: g_ptr_array_add (garray.c:1225)
==2395== by 0x4199A82: g_file_info_list_attributes (gfileinfo.c:642)
==2395== by 0x80492B7: test_g_file_info (g-file-info.c:86)
Bug #628331.
And use g_assert_[no_]error().
==2392== 49 (24 direct, 25 indirect) bytes in 1 blocks are definitely lost in loss record 451 of 573
==2392== at 0x4005BDC: malloc (vg_replace_malloc.c:195)
==2392== by 0x4057094: g_malloc (gmem.c:134)
==2392== by 0x406F2D6: g_slice_alloc (gslice.c:836)
==2392== by 0x406F31B: g_slice_alloc0 (gslice.c:848)
==2392== by 0x403A8A6: g_error_new_literal (gerror.c:117)
==2392== by 0x403AC31: g_set_error_literal (gerror.c:314)
==2392== by 0x41B7619: g_output_stream_set_pending (goutputstream.c:1198)
==2392== by 0x41B5799: g_output_stream_write (goutputstream.c:210)
==2392== by 0x41B590B: g_output_stream_write_all (goutputstream.c:268)
==2392== by 0x8049B54: verify_iostream (readwrite.c:110)
Bug #628331.
==2392== 38 (16 direct, 22 indirect) bytes in 1 blocks are definitely lost in loss record 369 of 573
==2392== at 0x4005BDC: malloc (vg_replace_malloc.c:195)
==2392== by 0x4057094: g_malloc (gmem.c:134)
==2392== by 0x406F2D6: g_slice_alloc (gslice.c:836)
==2392== by 0x406F31B: g_slice_alloc0 (gslice.c:848)
==2392== by 0x413D5BB: g_type_create_instance (gtype.c:1867)
==2392== by 0x412372A: g_object_constructor (gobject.c:1482)
==2392== by 0x4122E1D: g_object_newv (gobject.c:1266)
==2392== by 0x4122B93: g_object_new (gobject.c:1178)
==2392== by 0x4225D74: _g_local_file_new (glocalfile.c:310)
==2392== by 0x4231897: g_local_vfs_get_file_for_path (glocalvfs.c:84)
==2392== by 0x41CF91C: g_vfs_get_file_for_path (gvfs.c:94)
==2392== by 0x41911B6: g_file_new_for_path (gfile.c:5898)
==2392== by 0x804A2B9: test_g_file_replace_readwrite (readwrite.c:235)
Bug #628331.
==2392== 38 (16 direct, 22 indirect) bytes in 1 blocks are definitely lost in loss record 368 of 573
==2392== at 0x4005BDC: malloc (vg_replace_malloc.c:195)
==2392== by 0x4057094: g_malloc (gmem.c:134)
==2392== by 0x406F2D6: g_slice_alloc (gslice.c:836)
==2392== by 0x406F31B: g_slice_alloc0 (gslice.c:848)
==2392== by 0x413D5BB: g_type_create_instance (gtype.c:1867)
==2392== by 0x412372A: g_object_constructor (gobject.c:1482)
==2392== by 0x4122E1D: g_object_newv (gobject.c:1266)
==2392== by 0x4122B93: g_object_new (gobject.c:1178)
==2392== by 0x4225D74: _g_local_file_new (glocalfile.c:310)
==2392== by 0x4231897: g_local_vfs_get_file_for_path (glocalvfs.c:84)
==2392== by 0x41CF91C: g_vfs_get_file_for_path (gvfs.c:94)
==2392== by 0x41911B6: g_file_new_for_path (gfile.c:5898)
==2392== by 0x8049F23: test_g_file_create_readwrite (readwrite.c:183)
Bug #628331.
==2392== 38 (16 direct, 22 indirect) bytes in 1 blocks are definitely lost in loss record 367 of 573
==2392== at 0x4005BDC: malloc (vg_replace_malloc.c:195)
==2392== by 0x4057094: g_malloc (gmem.c:134)
==2392== by 0x406F2D6: g_slice_alloc (gslice.c:836)
==2392== by 0x406F31B: g_slice_alloc0 (gslice.c:848)
==2392== by 0x413D5BB: g_type_create_instance (gtype.c:1867)
==2392== by 0x412372A: g_object_constructor (gobject.c:1482)
==2392== by 0x4122E1D: g_object_newv (gobject.c:1266)
==2392== by 0x4122B93: g_object_new (gobject.c:1178)
==2392== by 0x4225D74: _g_local_file_new (glocalfile.c:310)
==2392== by 0x4231897: g_local_vfs_get_file_for_path (glocalvfs.c:84)
==2392== by 0x41CF91C: g_vfs_get_file_for_path (gvfs.c:94)
==2392== by 0x41911B6: g_file_new_for_path (gfile.c:5898)
==2392== by 0x8049E30: test_g_file_open_readwrite (readwrite.c:153)
Bug #628331.
==2389== 84 (44 direct, 40 indirect) bytes in 1 blocks are definitely lost in loss record 299 of 315
==2389== at 0x4005BDC: malloc (vg_replace_malloc.c:195)
==2389== by 0x4057094: g_malloc (gmem.c:134)
==2389== by 0x406F2D6: g_slice_alloc (gslice.c:836)
==2389== by 0x406F31B: g_slice_alloc0 (gslice.c:848)
==2389== by 0x413D5BB: g_type_create_instance (gtype.c:1867)
==2389== by 0x412372A: g_object_constructor (gobject.c:1482)
==2389== by 0x4122E1D: g_object_newv (gobject.c:1266)
==2389== by 0x4122B93: g_object_new (gobject.c:1178)
==2389== by 0x41AF54C: g_memory_input_stream_new (gmemoryinputstream.c:199)
==2389== by 0x8048BD1: test_read_chunks (memory-input-stream.c:40)
Bug #628331.
==2389== 59 (24 direct, 35 indirect) bytes in 1 blocks are definitely lost in loss record 290 of 315
==2389== at 0x4005BDC: malloc (vg_replace_malloc.c:195)
==2389== by 0x4057094: g_malloc (gmem.c:134)
==2389== by 0x406F2D6: g_slice_alloc (gslice.c:836)
==2389== by 0x406F31B: g_slice_alloc0 (gslice.c:848)
==2389== by 0x403A8A6: g_error_new_literal (gerror.c:117)
==2389== by 0x403AC31: g_set_error_literal (gerror.c:314)
==2389== by 0x41AFD15: g_memory_input_stream_truncate (gmemoryinputstream.c:517)
==2389== by 0x41BAC0F: g_seekable_truncate (gseekable.c:174)
==2389== by 0x8049595: test_truncate (memory-input-stream.c:123)
Bug #628331.
==2530== 13 bytes in 1 blocks are definitely lost in loss record 373 of 681
==2530== at 0x4005BDC: malloc (vg_replace_malloc.c:195)
==2530== by 0x4057094: g_malloc (gmem.c:134)
==2530== by 0x40573DB: g_malloc_n (gmem.c:281)
==2530== by 0x40717FC: g_strdup (gstrfuncs.c:101)
==2530== by 0x4147F56: value_lcopy_string (gvaluetypes.c:313)
==2530== by 0x4123F0B: g_object_get_valist (gobject.c:1643)
==2530== by 0x41240FF: g_object_get (gobject.c:1731)
==2530== by 0x804A4BA: test_basic (gsettings.c:28)
Bug #628331.
Allow modifying a GDBusMessage in a filter function and also add tests
for this. This breaks API but leaves ABI (almost) intact - at least
dconf's GSettings backend (the only big user I know of) will keep
working.
https://bugzilla.gnome.org/show_bug.cgi?id=624546
Signed-off-by: David Zeuthen <davidz@redhat.com>
==26538== 145 (24 direct, 121 indirect) bytes in 1 blocks are definitely lost in loss record 765 of 790
==26538== at 0x4005BDC: malloc (vg_replace_malloc.c:195)
==26538== by 0x405233C: g_malloc (gmem.c:134)
==26538== by 0x406A57E: g_slice_alloc (gslice.c:836)
==26538== by 0x406A60C: g_slice_copy (gslice.c:858)
==26538== by 0x4035C5A: g_error_copy (gerror.c:160)
==26538== by 0x41B6387: g_simple_async_result_set_from_error (gsimpleasyncresult.c:638)
==26538== by 0x41FCDEB: g_dbus_connection_call_done (gdbusconnection.c:4808)
==26538== by 0x41B682E: g_simple_async_result_complete (gsimpleasyncresult.c:762)
==26538== by 0x41B686A: complete_in_idle_cb (gsimpleasyncresult.c:772)
==26538== by 0x404DA7C: g_idle_dispatch (gmain.c:4224)
==26538== by 0x4049FCD: g_main_dispatch (gmain.c:2119)
==26538== by 0x404B2C1: g_main_context_dispatch (gmain.c:2672)
==26538== by 0x404B716: g_main_context_iterate (gmain.c:2750)
==26538== by 0x404BE7F: g_main_loop_run (gmain.c:2958)
==26538== by 0x804B5CC: test_connection_send (gdbus-connection.c:407)
==26538== by 0x4073D04: test_case_run (gtestutils.c:1174)
Bug #627187.
==25403== 49 (24 direct, 25 indirect) bytes in 1 blocks are definitely lost in loss record 603 of 787
==25403== at 0x4005BDC: malloc (vg_replace_malloc.c:195)
==25403== by 0x405233C: g_malloc (gmem.c:134)
==25403== by 0x406A57E: g_slice_alloc (gslice.c:836)
==25403== by 0x406A5C3: g_slice_alloc0 (gslice.c:848)
==25403== by 0x4035B4E: g_error_new_literal (gerror.c:117)
==25403== by 0x4035ED9: g_set_error_literal (gerror.c:314)
==25403== by 0x41F6434: g_dbus_connection_close_sync (gdbusconnection.c:1284)
==25403== by 0x804A861: test_connection_life_cycle (gdbus-connection.c:158)
==25403== by 0x4073D04: test_case_run (gtestutils.c:1174)
==25403== by 0x4073FC2: g_test_run_suite_internal (gtestutils.c:1223)
==25403== by 0x4074077: g_test_run_suite_internal (gtestutils.c:1233)
==25403== by 0x4074077: g_test_run_suite_internal (gtestutils.c:1233)
==25403== by 0x40741FB: g_test_run_suite (gtestutils.c:1274)
==25403== by 0x40733E5: g_test_run (gtestutils.c:877)
==25403== by 0x804DC92: main (gdbus-connection.c:1024)
Bug #627187.
Add GZlibCompressor:file-info property. If it contains a non-NULL
GFileInfo, and the compressor is in GZIP mode, the filename and
modification time from the file info are written to the GZIP header
in the output data.
Add GZlibDeompressor:file-info property. If the decompressor is in GZIP
mode, and the GZIP data contains a GZIP header, the filename and
modification time are read from it, stored in a GFileInfo, and the
file-info property is notified.
Bug #617691.
If sending a lot of data and/or the other peer is not reading it, then
socket buffers can overflow. This is communicated from the kernel by
returning EAGAIN. In GIO, it is modelled by g_output_stream_write()
and g_socket_send_message() returning G_IO_ERROR_WOULD_BLOCK.
It is also problematic that that we're using synchronous IO in the
shared GDBus IO thread. It means that one GDBusConnection can lock up
others.
It turns out that by porting from g_output_stream_write() to
g_output_stream_write_async() we fix the EAGAIN issue. For GSocket, we
still need to handle things manually (by creating a GSource) as
g_socket_send_message() is used.
We check the new behavior in Michael's producer/consumer test case (at
/gdbus/overflow in gdbus-peer.c) added in the last commit.
Also add a test case that sends and receives a 20 MiB message.
Also add a new `transport' G_DBUS_DEBUG option so it is easy to
inspect partial writes:
$ G_DBUS_DEBUG=transport ./gdbus-connection -p /gdbus/connection/large_message
[...]
========================================================================
GDBus-debug:Transport:
>>>> WROTE 128000 bytes of message with serial 4 and
size 20971669 from offset 0 on a GSocketOutputStream
========================================================================
GDBus-debug:Transport:
>>>> WROTE 128000 bytes of message with serial 4 and
size 20971669 from offset 128000 on a GSocketOutputStream
========================================================================
GDBus-debug:Transport:
>>>> WROTE 128000 bytes of message with serial 4 and
size 20971669 from offset 256000 on a GSocketOutputStream
[...]
========================================================================
GDBus-debug:Transport:
>>>> WROTE 43669 bytes of message with serial 4 and
size 20971669 from offset 20928000 on a GSocketOutputStream
[...]
========================================================================
GDBus-debug:Transport:
<<<< READ 16 bytes of message with serial 3 and
size 20971620 to offset 0 from a GSocketInputStream
========================================================================
GDBus-debug:Transport:
<<<< READ 15984 bytes of message with serial 3 and
size 20971620 to offset 16 from a GSocketInputStream
========================================================================
GDBus-debug:Transport:
<<<< READ 16000 bytes of message with serial 3 and
size 20971620 to offset 16000 from a GSocketInputStream
[...]
========================================================================
GDBus-debug:Transport:
<<<< READ 144000 bytes of message with serial 3 and
size 20971620 to offset 20720000 from a GSocketInputStream
========================================================================
GDBus-debug:Transport:
<<<< READ 107620 bytes of message with serial 3 and
size 20971620 to offset 20864000 from a GSocketInputStream
OK
https://bugzilla.gnome.org/show_bug.cgi?id=626748
Signed-off-by: David Zeuthen <davidz@redhat.com>
GSocket has a timeout flag now, but when using GSocketClient there was
no way to set the timeout until after connecting (or failing). Fix
that by adding a timeout property to GSocketClient.
The GClosure API is a bit funky (and badly documented), and requires
you to set a marshaller on the closure, and the marshaller has an
implicit 'this' argument, and the caller is reponsible for unsetting
the values after invoking the closure.
I've added some calls of the _with_closures variants to the
gdbus-names test now.
The D-Bus spec mentions exactly what header fields are required for
various message types. Add tests for this as well.
Also disallow empty interfaces for signals since the D-Bus spec says
this is Verboten already.
Signed-off-by: David Zeuthen <davidz@redhat.com>
Also use this in the test cases to check that serialization to and
from both big and little endian works.
Signed-off-by: David Zeuthen <davidz@redhat.com>
the FdSource was calling g_cancellable_disconnect while holding the
main context lock, which is bad news if the ::cancelled handler is
trying to get that lock to wake up the mainloop...
Bug 586432
When binding a boolean setting to a boolean property, invert the values.
This avoids the requirement for writing a pair of mapping functions for
this extremely common case.
Add a test.
https://bugzilla.gnome.org/show_bug.cgi?id=625833
Don't do too much work in the finalizer - in particular, there's no
need to send RemoveMatch() messages to the bus daemon since we're
going to sever the connection and the bus will garbage collect
anyway. In this case it crashed the process.
Also add a test case that checks that the appropriate GDestroyNotify
callbacks are called when unreffing a connection with either 1)
exported objects; 2) signal subscriptions or 3) filter functions
.. yes, ideally apps would unregister such callbacks before giving up
their ref but that's not how things work :-)
Signed-off-by: David Zeuthen <davidz@redhat.com>
- Make GCredentials instance and class structures private so it can't
be subclassed and we don't have to worry about ABI compat
issues. This also allows us to get rid of the GCredentialsPrivate
struct.
- Add a GCredentialsType enumeration that is used whenever exchanging
pointers with the user. This allows us to support OSes with
multiple native credential types. In particular, it allows
supporting OSes where the native credential evolves or even changes
over time.
- Add g_socket_get_credentials() method.
- Add tests for g_socket_get_credentials(). Right now this is in the
GDBus peer-to-peer test case but we can change that later.
- Move GTcpConnection into a separate gtk-doc page as was already
half-done with GUnixConnection. Also finish the GUnixConnection
move and ensure send_credentials() and receive_credentials()
methods are in the docs. Also nuke comment about GTcpConnection
being empty compared to its superclass.
Signed-off-by: David Zeuthen <davidz@redhat.com>
This allows sending and receiving D-Bus messages with instances of the
'h' D-Bus type. Unlike libdbus-1's dbus_message_iter_get_basic()
method, g_variant_get_handle() does not return a duplicated unix file
descriptor (that must be closed with close(2)) - instead, it returns
an index that can be used to get/dup the file descriptor from a
GUnixFDList object that can be obtained from the GDBusMessage object.
Signed-off-by: David Zeuthen <davidz@redhat.com>
This is currently unused but might be useful in the future. For
example, it might be nice with a way to bypass the current queue of
outgoing messages - having a flag enumeration allows us to add a
G_DBUS_SEND_MESSAGE_FLAGS_BYPASS_QUEUE etc. etc.
This commit breaks ABI and API. Users of the (rarely used) API to send
messages will have to port to this new API.
Signed-off-by: David Zeuthen <davidz@redhat.com>
This is currently unused but will probably be useful in the
future. For example, we could have a _ARG0_IS_PATH to specify that
arg0 should be used for arg0path.
This commit breaks API and ABI. Users of
g_dbus_connection_signal_subscribe() will need to port to this new
version.
Signed-off-by: David Zeuthen <davidz@redhat.com>
Return a NULL terminated C array instead of a GPtrArray
Also, document that %NULL is a permitted return value and clarify its
meaning.
Finally, avoid calling the enumeration function during dispatch when the
G_DBUS_SUBTREE_FLAGS_DISPATCH_TO_UNENUMERATED_NODES flag was given.
... so it is async, cancelable and returns an error. Also provide a
synchronous version.
This is an API/ABI break but it is expected that only very few
applications use this API.
Signed-off-by: David Zeuthen <davidz@redhat.com>
- add G_VARIANT_TYPE_BYTESTRING, _BYTESTRING_ARRAY, _STRING_ARRAY
- remove g_variant_{new,get}_byte_array functions
- add g_variant_{new,get,dup}_bytestring{,_array} functions
- remove undocumented support for deserialising arrays of objectpaths
or signature strngs using g_variant_get_strv()
- add and document new format strings '^ay', '^&ay', '^aay' and '^a&ay'
- update GApplication to use the new API
- update GSettings binding code to use the new API
- add tests
While this a dangerous thing to allow (collissions, reply_serial not
matching up etc.), the added flexibility makes this a good trade-off -
for example, with this feature, it's now a lot easier to build message
routers.
Signed-off-by: David Zeuthen <davidz@redhat.com>
Add a <flags> tag to the schema file format and a flags='' attribute to
go along with. Add some extra test cases for those.
Add new g_settings_{get,set}_flags() calls and support binding to
GParamSpecFlags properties. Add test cases.
Things will still work fine if the GDBusInterfaceInfo is allocated
statically because if so the ref_count will be -1.
Signed-off-by: David Zeuthen <davidz@redhat.com>
Without this guarantee, peer-to-peer connections are not very
useful. However, with this guarantee it's possible to export objects
in a handler for the GDBusServer::new-connection signal.
There are two caveats with this patch
- it won't work on message bus connections
- we don't queue up messages to be written
that can be addresses later if needed.
https://bugzilla.gnome.org/show_bug.cgi?id=623142
Signed-off-by: David Zeuthen <davidz@redhat.com>
Add support for extends='' and list-of='' tags to the <schema> element.
The attributes are parsed and some sanity-checking is done but currently
nothing happens as a result.
Add some tests.
Either child_watch_source or timeout_source will already have been
destroyed after we finish the loop, and it's not safe to call
g_source_destroy() on it a second time unless we're still holding a
ref on it.
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>
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>
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>
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
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.
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>
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.
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
This is to match g_dbus_connection_new(). This extension allows us to
extend GDBusAuthObserver to also be used in client-side authentication
in the future (right now it's only used on the server-side).
This is needed to e.g. allow encoding maybe types (once we add
G_DBUS_CAPABILITY_FLAGS_MAYBE_TYPES) if, and only if, that capability
has been negotiated with the peer (via authentication).
Also make the gdbus-example-server include some example
annotations. The output looks like this:
$ gdbus introspect --session --dest org.gtk.GDBus.TestServer --object-path /org/gtk/GDBus/TestObject
node /org/gtk/GDBus/TestObject {
interface org.freedesktop.DBus.Properties {
methods:
Get(in s interface_name,
in s property_name,
out v value);
GetAll(in s interface_name,
out a{sv} properties);
Set(in s interface_name,
in s property_name,
in v value);
signals:
PropertiesChanged(s interface_name,
a{sv} changed_properties);
};
interface org.freedesktop.DBus.Introspectable {
methods:
Introspect(out s xml_data);
};
interface org.freedesktop.DBus.Peer {
methods:
Ping();
GetMachineId(out s machine_uuid);
};
@org.gtk.GDBus.Annotation("OnInterface")
@org.gtk.GDBus.Annotation("AlsoOnInterface")
interface org.gtk.GDBus.TestInterface {
methods:
@org.gtk.GDBus.Annotation("OnMethod")
HelloWorld(in s greeting,
out s response);
EmitSignal(@org.gtk.GDBus.Annotation.("OnArg")
in d speed_in_mph);
GimmeStdout();
signals:
@org.gtk.GDBus.Annotation("Onsignal")
VelocityChanged(d speed_in_mph,
@org.gtk.GDBus.Annotation.("OnArg_NonFirst")
s speed_as_string);
properties:
@org.gtk.GDBus.Annotation("OnProperty")
@org.gtk.GDBus.Annotation("OnAnnotation_YesThisIsCrazy")
readonly s FluxCapicitorName = 'DeLorean';
readwrite s Title = 'Back To C!';
readonly s ReadingAlwaysThrowsError;
readwrite s WritingAlwaysThrowsError = "There's no home like home";
writeonly s OnlyWritable;
readonly s Foo = 'Tick';
readonly s Bar = 'Tock';
};
};
This makes it possible to use the cached properties mechanism even if
constructing the proxy with the DO_NOT_LOAD_PROPERTIES flag.
This is useful for cases where you obtain the and track object
properties out-of-band. For example, in udisks, the plan is to have
something like this
Manager.GetObjects (out ao paths, out aa{sa{sv}} all_properties);
Manager.ObjectAdded (o path, a{sa{sv}} all_properties);
Manager.ObjectChanged (o path, a{sa{sv}} all_properties);
Manager.ObjectRemoved (o path, a{sa{sv}} all_properties);
E.g. the first GetObjects() call will return *all* data about *all*
exported objects. Further, this way a client will only need to listen
these three signals (three AddMatch) on the Manager object and it will
never need to do GetAll() etc (e.g. can use DO_NOT_LOAD_PROPERTIES).
(Of course this only works if the client is interested in all
objects... while this is true for udisks it is generally not true for
other D-Bus services).
Also use expected_interface to check for programming errors.
These are included wholesale in the docs, and the copyright
headers make them even more overwhelming. Plus, we don't have
copyright headers on examples anywhere else.
Lots of people been suggesting this. We still use MethodInvocation /
method_invocation for handling incoming method calls so use call()
instead of invoke_method() helps to separate the client and server
facilities. Which is a good thing(tm).
Things compile and the test-suite passes. Still need to hook up
gio.symbols and docs. There are still a bunch of TODOs left in the
sources that needs to be addressed.
Signed-off-by: David Zeuthen <davidz@redhat.com>
There are apparently two incompatible ways of naming abstract sockets:
pad the sockaddr with 0s and use the entire thing as the name, or else
don't, and just pass a shorter length value to the relevant functions.
We previously only supported the former method. Add support for the
latter.
Also correctly handle "anonymous" unix sockaddrs (eg, the client side
of a connection, or a socketpair() socket), and add unix domain socket
support to the socket-client and socket-server test programs to make
sure this all works.
https://bugzilla.gnome.org/show_bug.cgi?id=615960
Gschema-compile uses glob which is available on Unix only. Thus can't
run the gschema-compile test except on Unix either.
To avoid an Automake error, comment out the SOURCES and LDADD of
unix-streams which for some reason has been commented out from
TEST_PROGS.
Can't use a Makefile.am target called foo_PROGRAMS for random files
that aren't actually programs, as Automake assumes EXEEXT should be
appended to the file names.
Correspond to GUnixInputStream and GUnixOutputStream. No true async
support though. But that is how the Win32 API is, for files not
explicitly opened for so-called overlapped IO.
The API to create these streams takes Win32 HANDLEs. Not file
descriptors, because file descriptors are specific to the C library
used. The user code and GLib might be using different C libraries.
Also add a test program for the new classes, and a gio-windows-2.0.pc
file.
It turns out that the way this worked did not work out for the current
main usecase (gedit) due to issues with how this is best integrated
with GtkTextView. So, in order to not have to support an unused non-ideal
API forever we remove this before its been in a stable release.
The basic feature seems to have some utility though, so we hope for it
to eventually return in a better form.
Some buildd environments have an unwritable $HOME, which makes the
test that looks for an unexisting file there fail. Use $TMP instead,
which should be more reliable.
https://bugzilla.gnome.org/show_bug.cgi?id=610860
root can access and write to a directory when it doesn't have
exec and write permissions respectively. So expect the tests that
check that to succeed rather than to fail when running as root.
https://bugzilla.gnome.org/show_bug.cgi?id=552912
GFile allows for the possibility that external implementations may not
support thread-default contexts yet, via
g_file_supports_thread_contexts(). GVolumeMonitor is not yet
thread-default-context aware.
Add a test program to verify that basic gio async ops work correctly
in non-default contexts.
http://bugzilla.gnome.org/show_bug.cgi?id=579984
Currently, to implement cancellability correctly, all synchronous
calls to GSocket must be preceded by a g_socket_condition_wait() call,
(even though GSocket does this internally as well) and all
asynchronous calls must do occasional manual
g_cancellable_is_cancelled() checks. Since it's trivial to do these
checks inside GSocket instead, and we don't particularly want to
encourage people to use the APIs non-cancellably, move the
cancellation support into GSocket and simplify the existing callers.
http://bugzilla.gnome.org/show_bug.cgi?id=586797
In particular, targets with weight 0 should be very UNlikely to be
selected, not very likely, as they were before. However, even ignoring
that bug in the logic, there was an additional bug (swapping list
items would cause the 0-weight items to get re-ordered incorrectly
anyway), and the code contained several fencepost errors.
This patch also adds gio/tests/srvtarget.c, which confirms that for a
sample list of targets, we now generate all possible correct random
sortings and no incorrect sortings, and the correct sortings occur in
roughly the expected proportions (though if the current code is
still wrong, those proportions may be wrong as well).
http://bugzilla.gnome.org/show_bug.cgi?id=583398
Previously we saved the location in various places which is unnecessary
and sometimes even wrong. For instance, we saved the address we bound to
which may not have the final port set.
glib/pcre/pcre_ucp_search_funcs.c, glib/pcre/pcre_valid_utf8.c: add
back missing config.h includes, and this time add them to the copies
in glib/update-pcre/ too so they don't get lost again on the next PCRE
update.
glib/garray.c, glib/gbase64.c: fix signed/unsigned pointer casts
gio/xdgmime/xdgmimeglob.c: remove unused variable
gio/tests/live-g-file.c: fix printf args on x86_64
tests/Makefile.am, tests/regex-test.c: remove redundant -DENABLE_REGEX
Higher-level wrappers around GResolver. GSocketConnectable provides an
interface for synchronously or asynchronously iterating multiple
socket addresses, with GNetworkAddress and GNetworkService providing
interfaces based on hostname and SRV record resolution.
Part of #548466.
GResolver provides asynchronous (and synchronous-but-cancellable) APIs
for resolving hostnames, reverse-resolving IP addresses back to
hostnames, and resolving SRV records. Part of #548466.
2009-02-26 Alexander Larsson <alexl@redhat.com>
Bug 540461 – g_memory_output_stream_get_data_size() doesn't behave as document
* gmemoryoutputstream.c:
Track actual valid size, even if we later seek back.
* tests/memory-output-stream.c:
Add testcase
svn path=/trunk/; revision=7916
2009-01-28 Ryan Lortie <desrt@desrt.ca>
Bug 568575 – _async functions for GDataInputStream
* gdatainputstream.h:
* gdatainputstream.c: add _async versions of read_line and read_until.
* gio.symbols:
* ../docs/reference/gio/gio-sections.txt: add new functions
* tests/sleepy-stream.c: new test case for async read line
* tests/Makefile.am: add new test
svn path=/trunk/; revision=7835
2009-01-20 Ryan Lortie <desrt@desrt.ca>
Bug 568394 – dropping the last reference to a stream filter closes the
base stream
* gfilterinputstream.h:
* gfilterinputstream.c: add "close-base-stream" property and only
close the base stream if it is true. issue async close callbacks from
correct source object.
* gfilteroutputstream.h:
* gfilteroutputstream.c: add a "close-base-stream" property and only
close the base stream if it is true. issue async close callbacks from
correct source object.
* gbufferedoutputstream: check g_filter_output_stream_get_close_base()
before closing the base stream. fix invalid source tag comparison in
close_async (was comparing to flush_async).
* ../docs/reference/gio/gio-sections.txt:
* gio.symbols: add
g_filter_{in,out}put_stream_{g,s}et_close_base_stream
* tests/filter-streams.c: new test cases
* tests/Makefile.am: add new test
* tests/.gitignore: add new test
svn path=/trunk/; revision=7825
2009-01-05 Ryan Lortie <desrt@desrt.ca>
* tests/.gitignore: improve
* tests/Makefile.am: add new simple-async-result test
* tests/simple-async-result.c: new file to test GSimpleAsyncResult
svn path=/trunk/; revision=7767
2008-11-28 Matthias Clasen <mclasen@redhat.com>
Bug 547481 – g_data_input_stream_read_line behaves not as stated in
the docs
* gdatainputstream.c (g_data_input_stream_read_line): Behave as
documented and include the line end in the returned string.
Pointed out by Paul Pogonyshev.
* tests/data-input-stream.c: Fix the read_line test to test the
documented behaviour.
svn path=/trunk/; revision=7694
2008-11-28 Matthias Clasen <mclasen@redhat.com>
Bug 562393 – g_buffered_input_stream_read_byte broken if data
available
* gio/gbufferedinputstream.c (g_buffered_input_stream_read_byte): Fix
handling of buffered content. Patch by Philip Withnall
* gio/tests/buffered-input-stream.c: Add a testcase for this bug.
* gio/tests/Makefile.am: And build it
svn path=/trunk/; revision=7686
Bug 509446 - portable blocking gio cancellation
* gcancellable.c (g_cancellable_make_pollfd): New method to make a
GPollFD for a cancellable (which is slightly more complicated on
Windows than Unix).
* gunixinputstream.c (g_unix_input_stream_read):
* gunixoutputstream.c (g_unix_output_stream_write): Use
g_cancellable_make_pollfd() and g_poll() rather than using poll()
directly.
* tests/unix-streams.c: test of GUnixInputStream,
GUnixOutputStream, and GCancellable.
svn path=/trunk/; revision=7553
2008-07-01 Cody Russell <bratsche@gnome.org>
* gio/gioenums.h:
* gio/giotypes.h:
Moved all relevant typedefs into these files.
* gio/*.[ch]:
Updated wrt added files.
Split types into separate file for easier maintainership. (#538564)
svn path=/trunk/; revision=7127
2008-06-12 Yevgen Muntyan <muntyan@tamu.edu>
* tests/live-g-file.c (sample_struct):
Use less fancy unicode filenames, so the test doesn't fail
on Mac OS X (#531476).
svn path=/trunk/; revision=7035
2008-03-13 Tomas Bzatek <tbzatek@redhat.com>
* tests/live-g-file.c:
Include live-g-file in standard set of tests, making a temporary
directory in source structure.
Clean target directory before the tests (write mode only)
svn path=/trunk/; revision=6699
2008-02-21 Alexander Larsson <alexl@redhat.com>
* gfile.[ch]:
* gio.symbols:
Add new g_file_has_prefix that does the same as g_file_contains_file.
Deprecate g_file_contains_file and add a macro that converts
it to g_file_has_prefix.
The reason for this change is that the contains_file() name seems to
imply that this does more work than what it does, but its really only
a name match (from #517086)
* gdummyfile.c:
* glocalfile.c:
* tests/g-file.c:
Update to match the above change.
svn path=/trunk/; revision=6546
2008-02-06 Tomas Bzatek <tbzatek@redhat.com>
* tests/Makefile.am:
* tests/live-g-file.c:
* tests/live-g-file.txt:
New GIO testing module working over real data
svn path=/trunk/; revision=6465
2008-01-22 Alexander Larsson <alexl@redhat.com>
* glocalfile.c:
(canonicalize_filename):
Canonicalize paths that start with more than
two slashes.
* tests/g-file.c:
(compare_two_files):
(test_g_file_new_for_path):
Test the above
svn path=/trunk/; revision=6353
