[patch] do not segfault when D-Bus connection is reused

[Timo Hoenig]

On Thu, 2006-08-24 at 11:19 -0400, Havoc Pennington wrote:

> Can you explain more what the crash is? This sounds like a memory leak, 
> not a crash?

Actually I don't think it is just a leak.  Once the connection is
re-established, dbus_pending_call_block() is getting called with pending
= 0.

The backtraces look like this:

#0  0xb7c5fbd7 in dbus_pending_call_get_completed () from /usr/lib/libdbus-1.so.3
#1  0xb7c5ffed in dbus_pending_call_block () from /usr/lib/libdbus-1.so.3
#2  0xb7c53239 in dbus_connection_send_with_reply_and_block () from /usr/lib/libdbus-1.so.3
#3  0xb7c4db18 in dbus_bus_name_has_owner () from /usr/lib/libdbus-1.so.3

(I didn't have time to capture a trace with debug info)

> > The attached patch makes dbus_bus_close() call
> > _dbus_bus_check_connection_and_unref() which decrements the
> > corresponding reference count of the hard reference.
> 
> I'd like to understand better why this has to be done synchronously and 
> not only asynchronously when the Disconnected message is processed.

If an application calls dbus_connection_close():  Is it supposed to
receive the "Disconnected" signal afterwards?

At least this does not happen, while debugging I eyed the ref/unref on
the connection and the reference of the hard reference was never
unref'ed.  It would have been unref'ed otherwise as
_dbus_bus_check_connection_and_unref() is called upon receiption of
"Disconnected".

> I'm guessing the problem is that dbus_bus_get returns an 
> already-disconnected connection?

Correct.

As the ref count for the closed connection is still 1.  Thus, the
connection is not being finalized properly.

> One thought is that doesn't seem avoidable in a threaded situation, so 
> maybe it should not cause an error if it currently does...

To keep it simple I reduced the code to the test case (cf. my previous
mail).  No threads are being used.

   Timo