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

List:       kde-commits
Subject:    Re: [kdelibs/KDE/4.7] kio/kio: fd leak fix by Ambroz Bizjak:
From:       Dawit A <adawit () kde ! org>
Date:       2011-08-18 22:39:11
Message-ID: CALa28R5OH6QxkcpMY=rU9VEX_6gHdgQW+KrHLpc4fbgnUZoy3g () mail ! gmail ! com
[Download RAW message or body]

Several hours. I stepped away from my desk and came back several hours
later only to discover that I cannot use the instance of Konqueror I
had already launched and browsed some sites with earlier. I could not
even use the instance to look at local files.

I will try your patch and see what output I get from it.

On Thu, Aug 18, 2011 at 2:36 PM, Ambroz Bizjak <ambrop7@gmail.com> wrote:
> I can't reproduce this. How much time did you have to wait? And it
> looks like a problem with Konqueror or the client side of KIO, not the
> slaves.
> It would probably help to see why
> SocketConnectionBackend::listenForRemote() is failing. I'm attaching a
> patch to add some error messages.
>
> On Thu, Aug 18, 2011 at 7:10 PM, David Faure <faure@kde.org> wrote:
>> On Thursday 18 August 2011 02:25:16 Dawit A wrote:
>>> David,
>>
>> Cc'ing Ambroz.
>>
>>> I do not understand the point of this patch. It seems to want to
>>> delete all QObjects in the current process in order to fix a fd leak ?
>>
>> No, it doesn't delete all QObjects. Only those on which deleteLater() was
>> called. The added code simply "flushes out" these deleteLater so that they
>> actually happen.
>>
>>> Is that the intent ? If so, then there is a big big problem. After
>>> this patch was committed Konqueror completely stops working for me
>>> whenever I browse a given website, leave it alone for a long while,
>>> and come back to browse the same site I was viewing earlier. After
>>> that I cannot use that particular instance of Konqueror. I have to
>>> launch a new one.
>>
>> Off hand I have no idea why this would happen. I'm afraid you or Ambroz will
>> have to debug it. (e.g. by adding a qdebug in QObject::deleteLater to see
>> which objects are being scheduled for deletion?)
>>
>>> I see the following error message in my .xsession-errors file:
>>>
>>> konqueror(18947)/kio (Slave) KIO::Slave::createSlave: createSlave
>>> "https" for KUrl("<sensored>")
>>> konqueror(18947) KIO::SlavePrivate::SlavePrivate: Connection server
>>> not listening, could not connect
>>> klauncher(5035)/kio (KLauncher) KLauncher::requestSlave: KLauncher:
>>> launching new slave  "kio_http"  with protocol= "https"  args=
>>> ("https", "local:/tmp/ksocket-dalemayehu/klauncherMT5035.slave-socket",
>>> "")
>>> klauncher(5035)/kio (KLauncher) KLauncher::processRequestReturn:
>>> "kio_http" (pid 24120) up and running.
>>> kio_http(24120)/kio (KIOConnection) KIO::Connection::connectToRemote:
>>> Unknown requested KIO::Connection protocol=' "" ' ( "" )
>>> kio_http(24120)/kio (kioslave) KIO::SlaveBase::connectSlave: failed to
>>> connect to ""
>>> Reason: ""
>>> couldn't lock local file
>>> konqueror(18947)/kio (Slave) KIO::Slave::timeout: slave failed to
>>> connect to application pid= 24120  protocol= "https"
>>> konqueror(18947)/kio (Slave) KIO::Slave::timeout: Houston, we lost our
>>> slave, pid= 24120
>>> konqueror(18947)/kio (Slave) KIO::Slave::timeout: slave died pid =  24120
>>> konqueror(18947)/kio (AccessManager)
>>> KDEPrivate::AccessManagerReply::jobError: " couldn't lock local file
>>> couldn't lock local file
>>> couldn't lock local file
>>> couldn't lock local file
>>> couldn't lock local file
>>> couldn't lock local file
>>>
>>> Moreover, are not KIO::Scheduler and KLauncher the ones responsible
>>> for managing ioslave creation/deletion ? BTW, reverting this patch
>>> seems to solve the problem for me. I am still testing with longer wait
>>> periods before using the browser again, but so far doing so seems to
>>> have resolved the regression.

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