dbus_connection_send_with_reply_and_block eats 100% CPU then eventually times out

Ralf Habacker ralf at habacker.de
Tue Feb 3 05:17:19 PST 2015


Am 03.02.2015 um 07:51 schrieb Alex Brooks:
> Hi Ralf,
>
> I tried with the modifications you suggest (tracking number of
> iterations and time).
> There's a magic number: in all cases it starts failing after 300274
> iterations (100% repeatable):
That is what I recognized too.

I filed a bug for it https://bugs.freedesktop.org/show_bug.cgi?id=88896.

With the interface test app
https://bugs.freedesktop.org/attachment.cgi?id=113094 I tried to check
several interfaces to get an idea where the problem belongs too and got
the following results:

              path                                    results
1. /org/freedesktop/DBus  -> no problem
2. /org/freedesktop/login1 -> no problem
3. /fi/w1/wpa_supplicant1 -> no problem
4. /fi/w1/wpa_supplicant1/Interfaces/7  [1] -> with problems ...

[1] number may be different on your system

Probably a problem inside wpa_supplicant. .

> ... wait ~55min ...
You can remove the usleep() call to short the time until the problem
occurs (in the mentioned bug problems occurs after 8 minutes)

Ralf

>
> Alex
>
>
> On 01/02/15 03:12, Ralf Habacker wrote:
>>
>> Am 31.01.2015 um 16:10 schrieb Ralf Habacker:
>>>
>>> Am 31.01.2015 um 14:49 schrieb Ralf Habacker:
>>>>  
>>>>> 5 19:27, "Ralf Habacker" <ralf at habacker.de
>>>>> <mailto:ralf at habacker.de>> wrote:
>>>>>
>>>>>
>>>>>     Am 31.01.2015 um 05:04 schrieb Alex Brooks:
>>>>>     > Hi,
>>>>>     >
>>>>>     > I've been fighting for a long time with what now looks like
>>>>>     a libdbus
>>>>>     > bug.
>>>>>     > I have a cut-down test program which calls a dbus method of
>>>>>     > wpa_supplicant at 100Hz, it does this happily for several
>>>>>     hours then
>>>>>     > at some point the behaviour changes: any future calls sit at
>>>>>     100% CPU
>>>>>     > for 25sec then time out.
>>>>>
>>> After running about 54 minutes I got:
>>>
>>>  counts      time (ms)
>>> 300272 3245606 signalInfo rssi=-63
>>> 300273 3245616 signalInfo rssi=-63
>>> Error: wpa_supplicant DBus error in signalPoll: Did not receive a
>>> reply. Possible causes include: the remote application did not send
>>> a reply, the message bus security policy blocked the reply, the
>>> reply timeout expired, or the network connection was broken.
>>>
>> second run gave same results:
>> ...
>>
>> 300272 3548324 1 signalInfo rssi=-57
>> 300273 3548413 79 signalInfo rssi=-59
>> Error: wpa_supplicant DBus error in signalPoll: Did not receive a
>> reply. Possible causes include: the remote application did not send a
>> reply, the message bus security policy blocked the reply, the reply
>> timeout expired, or the network connection was broken.
>>
>> Sounds as a kind of limits reached. The counts are collected as shown
>> below:
>>
>>     while ( true )
>>     {
>>         try {
>>             int a = timer.elapsed();
>>             int rssi = signalPoll( *netDevInterfaceInterface_ );
>>             int b = timer.elapsed();
>>             cout << i++ << " " << b << " " << (b-a) << " signalInfo
>> rssi=" << rssi << endl;
>>         }
>>
>>> Ralf
>>>
>>>
>>> _______________________________________________
>>> dbus mailing list
>>> dbus at lists.freedesktop.org
>>> http://lists.freedesktop.org/mailman/listinfo/dbus
>>
>
>
> -- 
> ------------------------------
> Dr Alex Brooks
> Marathon Targets Pty Ltd
> Ph: +61 2 8090 7202
> Web: www.marathon-targets.com
> ------------------------------
>
>
> _______________________________________________
> dbus mailing list
> dbus at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dbus

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/dbus/attachments/20150203/70eebfb3/attachment-0001.html>


More information about the dbus mailing list