dbus_connection_send_with_reply_and_block eats 100% CPU then eventually times out

[Alex Brooks]

Hi Ralf,

Do you have a wlan0 on that computer?
(also note that the method in question (signalpoll)  is new in
wpa_supplicant v2.3).
On 31 Jan 2015 19:27, "Ralf Habacker" <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.
> > I don't think the problem is on the wpa_supplicant side: other clients
> > can simultaneously make this call without any problems, and restarting
> > the client fixes it.
> > [I'm running at 100Hz because the faster I run this loop, the faster
> > it reproduces the problem.  CPU load sits below 20% before I hit the
> > bug].
> >
> > I posted details and a sample program as a Qt bug report (I'm using
> > the QDBus wrapper and thought it might be a Qt bug initially):
> > https://bugreports.qt.io/browse/QTBUG-43550
> >
> > Does anyone have any thoughts?
> I compiled the testcase on opensuse 13.1 x86_64 and did run:
>
> sudo ./signalpoll
> getNetDevObjectPath(wlan0)
> getNetDevObjectPath : GetInterface result:  QDBusMessage(type=Error,
> service="", error name="fi.w1.wpa_supplicant1.InterfaceUnknown", error
> message="wpa_supplicant knows nothing about this interface.",
> signature="", contents=([]) )
> terminate called after throwing an instance of 'std::string'
>
> Regards
>  Ralf m
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/dbus/attachments/20150131/c9f16008/attachment.html>