Thread problem causing some calls to hang for 25

Carlsson, Johannes Johannes.Carlsson.x at
Wed May 19 23:02:39 PDT 2010

Hi Guys

At Sony Ericsson this problem was quite frequent when turning on and off Bluetooth on our Android phone (Xperia X10i mini). Sometimes this operation took ~25s extra. We also managed to reproduce the problem on a Google G1, but this was a bit harder to do. I also reproduced it very frequently by adding a delay for every 3:rd (or something) call to _dbus_connection_acquire_io_path right after the connection lock had been released (I think this was the place at least).

When looking into the code for _dbus_connection_acquire_io_path I noticed that it releases the connection lock for a while. During this period another thread might already read the response and either put it in the incoming messages queue or already flagged it as completed (depending on which thread/call that did the actual reading). In Android there are several threads accessing the dbus-library at the same time, one which is dispathing events (android_server_BluetoothEventLoop.cpp) which calls dbus_watch_handle and a number of threads that will call dbus_connection_send_with_reply (android_bluetooth_common.cpp).

I tested this solution and it fixed this problem spot on (I tested by leaving the phone over night with a special sw that turned on and off Bluetooth constantly). During this test we also found a fd leak in the Android code, but that is another story :)

Is this patch something you could consider applying?


>Em Segunda-feira 17 Maio 2010, às 09:46:53, Thiago Macieira escreveu:
>> Em Segunda-feira 17. Maio 2010, às 09.02.35, Redestig, Johan escreveu:
>> > Hi Guys,
>> > 
>> > As part of our Android efforts we have identified, and believe that we
>> > have a solution for a problem which causes some calls to hang for 25
>> > seconds. We uploaded a problem description and proposed solution here:
>> >
>> > 
>> > Similar problems are reported here:
>> >
>> >
>> > 
>> > We would really appreciate feedback on the proposed solution from the
>> > dbus experts.
>> Hi
>> The patch makes sense. I don't know if it solves the issue (I can't
>> reliably reproduce it), but I do have a bug report for Qt about a
>> threading issue. I'll see if that issue is reproducible and if the patch
>> has any impact.

>The Qt issue is I can 
>reproduce it reliably with and without the patch.
>So the patch doesn't fix the issue.
>It does make it that much rarer, though. I have another issue in a private 
>bugtracker for Maemo that shows considerable improvement. Instead of locking 
>up for 25 seconds every 10-15 attempts, it takes me more than 300 attempts to 
>get a lockup.

More information about the dbus mailing list