From c407f6b31ec3a67281ef98bb8d64616827e8d0e9 Mon Sep 17 00:00:00 2001 From: Simon McVittie Date: Fri, 25 Feb 2011 17:08:59 +0000 Subject: [PATCH 05/10] Comment some places where it's OK to unref a message despite holding locks In general, dbus_message_unref should be avoided while holding locks, because it can invoke arbitrary user callbacks (via attached data, or via DBusCounter). --- dbus/dbus-connection.c | 2 ++ dbus/dbus-pending-call.c | 2 ++ 2 files changed, 4 insertions(+), 0 deletions(-) diff --git a/dbus/dbus-connection.c b/dbus/dbus-connection.c index 3538ee3..f8605c3 100644 --- a/dbus/dbus-connection.c +++ b/dbus/dbus-connection.c @@ -4740,6 +4740,8 @@ dbus_connection_dispatch (DBusConnection *connection) if (preallocated == NULL) { + /* It's OK that this is finalized, because it hasn't been seen by + * anything that could attach user callbacks */ dbus_message_unref (reply); result = DBUS_HANDLER_RESULT_NEED_MEMORY; _dbus_verbose ("no memory for error send in dispatch\n"); diff --git a/dbus/dbus-pending-call.c b/dbus/dbus-pending-call.c index e1de656..6ec6dd9 100644 --- a/dbus/dbus-pending-call.c +++ b/dbus/dbus-pending-call.c @@ -351,6 +351,8 @@ _dbus_pending_call_set_timeout_error_unlocked (DBusPendingCall *pending, reply_link = _dbus_list_alloc_link (reply); if (reply_link == NULL) { + /* it's OK to unref this, nothing that could have attached a callback + * has ever seen it */ dbus_message_unref (reply); return FALSE; } -- 1.7.4.1