[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-commits
Subject:    Re: branches/KDE/4.4/kdelibs/nepomuk/core
From:       Sebastian Trüg <sebastian () trueg ! de>
Date:       2010-02-05 7:53:35
Message-ID: 4B6BCE7F.6060105 () trueg ! de
[Download RAW message or body]

David Faure wrote:
> On Wednesday 03 February 2010, Sebastian Trueg wrote:
>   
>> SVN commit 1084698 by trueg:
>>
>> Backport: less dbussy crashing.
>>
>>
>>  M  +7 -1      resourcedata.cpp
>>
>>
>> --- branches/KDE/4.4/kdelibs/nepomuk/core/resourcedata.cpp #1084697:1084698
>> @@ -673,12 +673,18 @@
>>                      //
>> +                    // We create a new dbus connection to protect us from
>> multi-thread related crashes. [...]
>>     
>
> Hi Sebastian,
>
> it seems to me that this commit introduces a severe regression.
> After a few hours of using KDE, there are tons of dbus connections showing
> up in `qdbus`.
> qdbus | wc -l is normally around 100 here; after starting akonadiserver, 140,
> but after running kontact for a few hours, I get 600, 800, 1000, 1200.
> At that point the system is so slow it's unusable.
>
> As this command shows (thanks thiago for the hint)
> qdbus org.freedesktop.DBus / org.freedesktop.DBus.GetConnectionUnixProcessID :1.346
> all the unnamed connections are from akonadiserver.
> Indeed, stopping akonadiserver removes all the unnamed dbus connections => back to 100.
>
> I tried reverting the above commit and restarting akonadiserver, problem still there,
> it's going up and up. But after also restarting kontact, the problem seems gone.
> I'm a bit puzzled; I thought those connections would be due to akonadiserver's
> use of nepomuk, not kontact's use of nepomuk; well it seems indirect
> (kontact -> akonadi -> nepomuk). Also, thiago didn't see how your commit (which he said
> was very very inefficient code), should leak dbus connections.
>
> Anyway; this looks to me like a major showstopper for the (already tagged) 4.4.0
> release: KDE becomes unusable after 8 hours of running...
>
>   
That is bad indeed. I know the code is very very inefficient. But
without the hack the thing crashes. Especially Strigi crashes all the
time after indexing N files. This is also related to the DBus bug which
causes so many problems. It would be great if Thiago could work around
that in QtDBus. Then such hacks would be unnecessary. Without a
workaround I do not really know what to do here...

Cheers,
Sebastian

[prev in list] [next in list] [prev in thread] [next in thread]