thread-safety of counters

Adrian Szyndela adrian.s at
Mon Feb 23 03:23:39 PST 2015

Let's consider a simple test program that:
1. creates a D-Bus connection;
2. creates a few threads that share the connection;
3. then, threads perform method calls over the connection.
A sample program is attached.

My question is: is dbus designed for such usage?

If answer is no, then I have another question: is there any place that
describes what is thread-safe in dbus and what is not?
If answer is yes, then I think there is a bug. I am able to trick the
sample program into a crash only by executing instructions in specific
order on ARM arch.

I used gdb in non-stop mode to handle threads independently.
I caught two threads in two points:
Thread 1. in _dbus_counter_ref() while adding a counter to an incoming
message (dbus/dbus-transport.c:1161, _dbus_transport_queue_messages());
Thread 2. in _dbus_counter_unref() on the same counter, while unrefing a
reply for another method call.

There are two messages involved, but both point to the same counter

Then, by careful stepping through assembler of ref/unref functions in
both threads I was able to generate refcount corruption. This resulted
in freeing the object prematurely, and eventually led to a crash.

As a conclusion, I suggest changing DBusCounter's refcount from int to
DBusAtomic, as in DBusMessage. A patch with this done is attached.

This might be related to bug reports:

as we have the same call stack trace when crashed. However, these are
generated on x86_64, and I am not sure if the described scenario is
possible on this arch.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: tt.c
Type: text/x-csrc
Size: 983 bytes
Desc: not available
URL: <>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: counter-thread-safety.patch
Type: text/x-patch
Size: 1305 bytes
Desc: not available
URL: <>

More information about the dbus mailing list