Problem/Bug? with dbus-daemon

[David Belser]

I Found the problem with my app  -

My method reply messages are going back on a different connection than
the original method calls are coming in on.

While this is not an unreasonable constraint on applications, it does
mean that a multi-threaded and/or multi-connection app needs to be
careful.

Dave

On Wed, May 28, 2008 at 5:22 PM, David Belser <thebelserturner at gmail.com> wrote:
> I have a C++ app that pushes a lot of message through the dbus-daemon.
> I'm getting errors from the daemon - "The maximum number of pending
> replies per connection has been reached"
>
> The problem appears to be in bus/connection.c - I found where the
> message is originated and added a _dbus_verbose to print the count of
> pending replies. The result is that the count just continues to
> increase. After going over the code and looking at verbose output here
> is what I found:
>
> I see the pending calls being added in bus_connections_expect_reply.
> I also see that cancel_pending_reply_data_free is being called via
> bus_transaction_execute_and_free - where it calls free_cancel_hooks.
>
> If I read it correctly, the pending reply gets added to a list for the
> connection in bus_connections_expect_reply. At the same time it adds
> cancel hooks - cancel_pending_reply and cancel_pending_reply_data_free
> to the transaction. When bus_transaction_execute_and_free gets called,
> it calls free_cancel_hooks which released the data for the pending
> reply but it doesn't remove it from the pending reply list. So the
> list continues to grow with pending replies that have been free'd.
>
> As an experiment, I changed both of the cancel hook functions to be -
> cancel_pending_reply - which both removes the reply from the list and
> also frees the reply.
>
> So maybe it's assumed that the reply will be removed before or when
> the transaction executes so freeing just data in the cancel hooks
> would be OK. But looking thru the code I can only find 2 places that
> pending replies are removed from the list:
>
> - bus_pending_reply_expired, which is clearly not the case here, the
> replies are immediate
> - bus_connection_drop_pending_replies, only called from
> bus_connection_disconnected which is
> also not happening in my case.
>
> This happens in both 1.1.20 and 1.2.1
> I noticed that there was rework done on connection.c for the bus
> expire list so I verified that I have the same problem with both
> versions.
>
> Is this a bug? I'd be surprised if it is. In the normal case where are
> pending replies supposed to be removed?
>
> Dave
>