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

List:       kde-devel
Subject:    Re: How to debug kioslave problems ? [Was: Problem opening
From:       David Faure <faure () kde ! org>
Date:       2006-04-04 18:25:18
Message-ID: 200604042025.18683.faure () kde ! org
[Download RAW message or body]

On Tuesday 04 April 2006 17:35, Pavel Troller wrote:
> Hi!
> I've made a new bunch of tests, trying to find, why konq crashes.
> > Hi!
> > Yes, it helped a lot. Now the stat(bluetooth:/) function is called and there
> > is no error from the slave.
> > However, konqueror crashes immediately:
> > 
> > kio_bluetooth: KioBluetooth::KioBluetooth()
> > kio (KSycoca): Trying to open ksycoca from /var/tmp/kdecache-patrol/ksycoca
> > kio_bluetooth: kio_bluetooth::stat(bluetooth:/)
> > kio (KRun): Finished
> > konqueror [kdeinit] bluetooth:/: krun.cpp:1096: virtual void \
> > KRun::slotStatResult(KIO::Job*): Assertion `m_bScanFile || m_bIsDirectory' \
> >                 failed.
> > KCrash: crashing... crashRecursionCounter = 2
> > KCrash: Application Name = konqueror path = <unknown> pid = 26408
> > 
> > Does it mean that there is something wrong with the data returned by the
> > slave ? I've looked at krun.cpp and it seems that the only possibility is that
> > KIO::UDS_FILE_TYPE entry is not present. But in kiobluetooth.cpp, there is
> > 
> > addAtom(entry, UDS_MIME_TYPE, mimeType); // this is empty for the failing call
> > addAtom(entry, UDS_FILE_TYPE, S_IFDIR);
> > addAtom(entry, UDS_GUESSED_MIME_TYPE, "inode/folder");
> > 
> > and I've verified that this code is really executed when the slave runs.
> > So what the hell is going wrong now ?
> I've verified that
> 1) addAtom is correctly called in the slave several times, setting all the
> above and much more (I've corrected inode/folder to inode/directory, but it
> has no effect at all), when creating the directory.
From stat(), right? We're not talking about listDir() at this point.

> 2) iteration loop in krun.cpp, starting around line 1071, is not executed even
> once, i.e. the list comes empty to it. It explains why the assert occurs.
> I cannot explain, why the stat() results are not transferred correctly, sorry.
> Is anybody willing to help me ?
OK so this is about kdelibs-3, not kdelibs-4. This lowers the chances of a bug in \
krun considerably...

Does the slave actually call statEntry() from stat(), with the uds entry?
Where's the code for that ioslave? extragear?

-- 
David Faure, faure@kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).

 
> > Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<


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