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