dbus-python 0.80rc1 release candidate

[Simon McVittie]

On Thu, 07 Dec 2006 at 17:04:58 -0500, John (J5) Palmieri wrote:
> On Wed, 2006-12-06 at 14:50 +0000, Simon McVittie wrote:
> > Release candidate 1 for dbus-python 0.80 is now available. Please
> > download, test, try to break it.
> 
> Still tracking it down but sugar no longer starts.  We are getting a
> connection != NULL assertion when calling
> dbus_connection_send_with_reply.

Assuming you're not mixing versions (in which case all bets are off):

- Functions matching dbus_connection_send* are only called from
  Connection_send_message, Connection_send_message_with_reply
  and Connection_send_message_with_reply_and_block

- All of those functions can only be called on a Connection or subclass

- Connections successfully allocated by Connection_NewConsumingDBusConnection
  should always have a non-NULL connection (if a NULL DBusConnection was
  passed, dbus_connection_set_data would crash)

- Connection_tp_new always calls Connection_NewConsumingDBusConnection

- Bus_tp_new always calls either Connection_tp_new or
  Connection_NewConsumingDBusConnection (although in verifying this, I
  did discover that connecting a Bus to a non-standard address wouldn't
  have worked)

- (any Connection *)->conn is only ever set NULL by Connection_tp_dealloc.

I suppose the tp_dealloc could conceivably explode if the Connection and its
filters/object path handlers participate in a reference cycle, *and* one of
the filters/object path handlers invokes a Connection method. Also,
crashes might occur in a threaded environment if you're ludicrously
unlucky? (I'm not sure whether that's actually possible or whether the
refcount machinery and the GIL protect us.)

I'll ponder that and see if it's possible to fix the invariant that every
Connection* always has a non-NULL DBusConnection*. Adding some assertions
would probably be a good move in any case.