dbus_connection_send_with_reply() is not safe if another thread is dispatching the connection
Submitted by Stian Skjelstad
Assigned to D-Bus Maintainers
Created attachment 22331 DBUS_VERBOSE=1 and gdb-backstraces (with comments).txt
dbus_connection_send_with_reply and all its users like dbus_connection_send_with_reply_and_block and dbus_g_proxy_begin_call_internal can randomly miss reply messages when using pending (async).
With the current design, the following scenario might happen (and sometime does) if the peer you are talking to is fast enough:
- dbus_connection_send_with_reply() dbus internals might send off the message straight away, and also retrieve a reply straigh away reply message finds its matching DBusPendingCall DBusPendingCall->function is NULL, so no call is done
- dbus_connection_send_with_reply finally returns
- dbus_pending_call_set_notify() sets the return notify-function
And there you are, your notify function is never called (you will never even receive a timeout error), and memory for maintaining the DBusPendingCall is leaked.
dbus_connection_send_with_reply() should perhaps have been replaced with a new function (with a new name) that has a new argument, a callback functions that configures the newly created DBusPendingCall structure, and dbus_connection_send_with_reply tagged dangerous/deprecated.
Sorry for tagging this blocker/highest, but atleast I find this bug to be quite severe, due to the main functions of dbus fail to function as expected/designed.
Attachment 22331, "DBUS_VERBOSE=1 and gdb-backstraces (with comments).txt":