Re: dbus_connection_send_with_reply_and_block eats 100% CPU then eventually times out

Ralf Habacker <ralf-aVxs2ipq/[email protected]>
Newsgroups gmane.comp.freedesktop.dbus
Message-ID <[email protected]>
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-aVxs2ipq/[email protected]
>>>>> <mailto:ralf-aVxs2ipq/[email protected]>> 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
>>> [email protected]
>>> 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
> [email protected]
> http://lists.freedesktop.org/mailman/listinfo/dbus

_______________________________________________
dbus mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/dbus
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.