libdbus _dbus_connection_block_pending_call blocks until timeout, even after reply is received

[Simon McVittie]

On Thu, 25 Jan 2018 at 11:39:44 +0000, Manish Narang wrote:
> On Friday 15 December 2017 11:46 PM, Simon McVittie wrote:
> > https://bugs.freedesktop.org/show_bug.cgi?id=102839#c12 outlines what I
> > think a solution should probably look like
> 
> I created and tested a patch (also attached herewith) based on your
> suggestions in https://bugs.freedesktop.org/show_bug.cgi?id=102839#c12
> The patch seems to fix the problem, and the test client successfully
> finishes all the calls without blocking.

That's reassuring. I've broken up your patch into smaller changes and
reverted some re-indentation, and I'll attach the results to the bug.

> If there is a formal channel to submit a patch for upstream acceptance,
> please let me know and I'll route the submission through there.

The formal channel is attaching patches to the bug tracking system,
preferably in `git format-patch` format so that we can provide the
same author/date attribution that you intended. For now I've used your
name and email address and the date of your mailing list post, and made
up some commit messages myself. Please post any follow-up messages as
comments on the bug.

> PS - libdbus version used for this exercise - 1.10.8

You should plan to upgrade to the latest 1.10.x release if possible
(currently 1.10.24), or backport the fixes that are relevant to
you. 1.10.8 has a potentially exploitable format string vulnerability
in some OS configurations (CVE-2015-0245), a known denial-of-service
regression in some OS configurations, a symlink attack in the nonce-tcp
transport, and several known memory leaks, all of which are fixed in or
before 1.10.24.

The supported versions of dbus are, most-preferred first:
* latest release (currently 1.12.2) from latest stable branch
  (currently dbus-1.12)
* latest release from each even-numbered branch that is still maintained
  (currently 1.10.24 from dbus-1.10, and 1.8.22 from dbus-1.8)
* latest development release from 'master' branch (not recommended for
  production use; there is currently no development release, but I'll
  release 1.13.0 soon)

> Also PS - I see intermittent failures saying -
> "dbus_connection_send_with_reply Method "add_numbers" with signature "s"
> on interface "com.test.dbus_example" doesn't exist".

This is a bug in the test code. You call
dbus_connection_read_write_dispatch() once per iteration, which results
in zero or more method calls being dispatched; but you don't have any
object path handlers registered, so libdbus doesn't think any objects
implement any methods.

When you call dbus_connection_pop_message(), that "steals" any further
messages that are queued for the next round of dispatching, but doesn't
do anything about messages that have already been dispatched while
dbus_connection_read_write_dispatch() was running.

To write a correct service using libdbus, either use
dbus_connection_register_object_path() (like test/test-service.c does;
preferred), or pick out and reply to method calls in a filter function
(like tools/dbus-echo.c does). To get the callback functions to
be called, either set the connection up with a main-loop like the
one provided by GLib (like at-spi2-core does; preferred), or call
dbus_connection_read_write_dispatch() in a loop (like tools/dbus-echo.c
does).

I'm aware that this is not easy or straightforward - libdbus is a
low-level library which tries to be all things to all people, and as a
result its API is a mess. I would recommend considering a different D-Bus
library, like GLib's GDBus (multi-thread-safe, portable, currently
un-optimized) or systemd's sd-bus (not safe for multi-threaded use, only
works on Linux, but simple and fast).

    smcv