Free the read buffer.
==26538== 4,096 bytes in 1 blocks are definitely lost in loss record 781 of 781
==26538== at 0x4005BDC: malloc (vg_replace_malloc.c:195)
==26538== by 0x4005C66: realloc (vg_replace_malloc.c:476)
==26538== by 0x405244D: g_realloc (gmem.c:181)
==26538== by 0x420E066: _g_dbus_worker_do_read_unlocked (gdbusprivate.c:780)
==26538== by 0x420E1D1: _g_dbus_worker_do_read (gdbusprivate.c:812)
==26538== by 0x420F14A: _g_dbus_worker_thread_begin_func (gdbusprivate.c:1318)
==26538== by 0x420D2ED: invoke_caller (gdbusprivate.c:266)
==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 0x420D2B5: shared_thread_func (gdbusprivate.c:248)
==26538== by 0x4077958: g_thread_create_proxy (gthread.c:1897)
==26538== by 0x57D918: start_thread (pthread_create.c:301)
==26538== by 0x4C6CBD: clone (clone.S:133)
Bug #627187.
==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.
This patch guarantees that g_output_stream_write() can never fail with
G_IO_ERROR_WOULD_BLOCK. Without such a guarantee, we would need some
kind of GIOPollable interface or some way to get an event when the
stream is writable again. Which is mostly useless considering that
this method is asynchronous anyway.
Note: this patch just codifies existing behavior - GUnixOutputStream,
GSocketOutputStream and other implementations already work this way.
See also bug 626748 comment 5 for how the GDBus code relies on this
guarantee.
https://bugzilla.gnome.org/show_bug.cgi?id=627071
Signed-off-by: David Zeuthen <davidz@redhat.com>
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>
This patch fixes this problem
Syscall param socketcall.sendmsg(msg.msg_control) points to uninitialised byte(s)
at 0x3D5B00EA60: __sendmsg_nocancel (syscall-template.S:82)
by 0x53F9790: g_socket_send_message (gsocket.c:2918)
by 0x540FDD0: g_unix_connection_send_credentials (gunixconnection.c:351)
by 0x542B93F: _g_dbus_auth_run_client (gdbusauth.c:618)
by 0x5438001: initable_init (gdbusconnection.c:2191)
by 0x53E09CC: g_initable_init (ginitable.c:105)
by 0x543F6E9: g_bus_get_sync (gdbusconnection.c:6091)
by 0x402C7E: test_connection_life_cycle (gdbus-connection.c:126)
by 0x4C7CABB: test_case_run (gtestutils.c:1174)
by 0x4C7CD84: g_test_run_suite_internal (gtestutils.c:1223)
by 0x4C7CE49: g_test_run_suite_internal (gtestutils.c:1233)
by 0x4C7CE49: g_test_run_suite_internal (gtestutils.c:1233)
Address 0x7fefff9fc is on thread 1's stack
Signed-off-by: David Zeuthen <davidz@redhat.com>
Previously if a GSocketConnection had a blocking GSocket, it would
sometimes block during asynchonous I/O, and if it had a non-blocking
socket, it would sometimes return G_IO_ERROR_WOULD_BLOCK from
synchronous I/O. This fixes the connection to not depend on the socket
state.
https://bugzilla.gnome.org/show_bug.cgi?id=616458
g_socket_client_connect_async() was always leaking its GCancellable,
and would also leak any GSocket that eventually failed to connect
after returning G_IO_ERROR_PENDING.
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.
Because g_simple_async_report_[g]error_in_idle() don't take a source tag
parameter, code that uses them can't currently use
g_simple_async_result_is_valid() (at least, not for the error case).
Bug 602417
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.
This prints all GDBusMethodInvocation API usage and is normally used
with the `incoming' option. Example:
# G_DBUS_DEBUG=incoming,return ./polkitd --replace
Entering main event loop
Connected to the system bus
Registering null backend at priority -10
[...]
Acquired the name org.freedesktop.PolicyKit1
[...]
========================================================================
GDBus-debug:Incoming:
<<<< METHOD INVOCATION org.freedesktop.PolicyKit1.Authority.RegisterAuthenticationAgent()
on object /org/freedesktop/PolicyKit1/Authority
invoked by name :1.26
serial 299
========================================================================
GDBus-debug:Return:
>>>> METHOD ERROR org.freedesktop.PolicyKit1.Error.Failed
message `Cannot determine session the caller is in'
in response to org.freedesktop.PolicyKit1.Authority.RegisterAuthenticationAgent()
on object /org/freedesktop/PolicyKit1/Authority
to name :1.26
reply-serial 299
[...]
========================================================================
GDBus-debug:Incoming:
<<<< METHOD INVOCATION org.freedesktop.PolicyKit1.Authority.RegisterAuthenticationAgent()
on object /org/freedesktop/PolicyKit1/Authority
invoked by name :1.2402
serial 25
========================================================================
GDBus-debug:Return:
>>>> METHOD RETURN
in response to org.freedesktop.PolicyKit1.Authority.RegisterAuthenticationAgent()
on object /org/freedesktop/PolicyKit1/Authority
to name :1.2402
reply-serial 25
Signed-off-by: David Zeuthen <davidz@redhat.com>
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>
We use g_assert() instead of setting the GError because it is a
programming error if the GVariant contains invalid data - see commit
5e6f762d61 for where the last hole in
GVariant was closed.
So if we can trust GVariant to only contain valid data (ignoring the
case where unsafe API such as g_variant_new_from_data() is used), why
g_assert() at all with costly g_utf8_validate() checks? Because a) it
is relatively inexpensive; and b) it helps find bugs such as the one
fixed in commit 5e6f762d61.
If performance is a concern we can play games like introducing
environment variables or other machinery to avoid such "costly"
checks. I doubt it will ever be an issue.
Also replace two "Hmm" TODO item with a static assert - the code that
serializes a gdouble into the D-Bus wire format by treating it as a
guint64 is indeed correct - endianess needs to be taken into account
(see the D-Bus reference implementation for similar code). But we want
to make sure that we're indeed using an architecture/compiler where a
gdouble takes up 8 bytes - hence the assertion.
Signed-off-by: David Zeuthen <davidz@redhat.com>
