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

Havoc Pennington hp at redhat.com
Thu Aug 24 08:46:33 PDT 2006


Timo Hoenig wrote:
> 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)
>

Is there an assertion failure message or a segfault - what's the crash?

Definitely need to track down the root cause here.

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

It's guaranteed to receive it, but it's in the message queue, so if you 
never dispatch() it won't be processed. In other words it arrives 
asynchronously.

> 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".

Of course, there may be a bug...

>> 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.

Right, but lack of finalization would be a leak not a crash - so we have 
some problem beyond that i.e. disconnected connections are somehow 
unsafe to use in certain ways.

Hmmm. I was just thinking, I'm not sure dbus_connection_close() on the 
dbus_bus_get() connections is strictly speaking allowed - or perhaps 
should not be allowed - it's very unclear what it means to disconnect a 
shared connection. I'd be interested in why your app is closing these as 
a side question.

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

What I was trying to say is that if it causes problems to return a 
disconnected connection from dbus_bus_get(), then this may not be a 
sufficient fix; because another thread can always disconnect it after 
dbus_bus_get already returned it.

So it's possible we need to fix (or document) things so that getting a 
disconnected bus connection is possible, and be sure it works OK (does 
not crash when following the rules for using shared connections).

Havoc


More information about the dbus mailing list