There's a tiny race condition here: static void dbus_message_cache_or_finalize(DBusMesasge *message) { ... _DBUS_LOCK (message_cache); ... message_cache[i] = message; ... out: _DBUS_UNLOCK (message_cache); _dbus_assert (message->refcount.value == 0); ... } If the message is cached, it's possible for another thread to remove the message from the cache and set the reference count to 1 between the unlock and the assertion check. I suspect this is causing gnome bug 369214, in which the gnome-vfs dbus code dies with this message: 24035: assertion failed "message->refcount.value == 0" file "dbus-message.c" line 672 function dbus_message_cache_or_finalize under multithreaded use. I've only seen this happen once or twice in (probably) hundreds of thousands of operations when I've been deliberately stressing it. Reporters of that bug and its duplicates don't seem to be able to reproduce it reliably.
Good catch - looks bogus indeed...
Created attachment 7905 [details] test programs A pair of test programs (client and server) that attempt to mimic gnome-vfs dbus usage. That is, each client thread has its own dbus connection, and each connection at the server is handled in a new thread. The client just throws empty messages at the server as fast as it can, and the server responds with messages containing a single integer (the number of requests handled by the thread). For me, this triggers the bug within a couple of minutes. After patching dbus to perform the check while still holding the lock, I've left them running for about half an hour with no problems.
Fixed in 1.0.x and 1.1.x, thanks!
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.