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

[John (J5) Palmieri]

Ya, this fix is not quite right.  You shouldn't be able to close a
shared connection.  We should most likely make close print a warning for
shared connections.  Why do we have a close and unref in the first
place?

On Thu, 2006-08-24 at 11:46 -0400, Havoc Pennington wrote:
> 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
> _______________________________________________
> dbus mailing list
> dbus at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dbus
--