Giving up

[Aaron J. Seigo]

On Friday 06 April 2007, Stephan Johach wrote:
> There is already a bug report about it.
>
> http://bugs.kde.org/show_bug.cgi?id=119222
>
> This one seems also related
>
> http://bugs.kde.org/show_bug.cgi?id=129152

i'm completely unfamiliar with the code, but looking at catalogmanagerview.cpp 
and those bug reports, this is what occurs to me:

it's interesting this works with dnotify, but not some other method. 

for that matter: which kdirnotify methods does this break under? inotify? i 
couldn't see anything about what people were using previously? that would be 
very useful information! Erik: do you know what your system uses for watching 
files?

anyways ... on file change, CatalogManagerView::directoryChanged gets called. 
this does a few very nasty things; it calls stopScan on the KDirLister when 
it starts and then startScan when directoryChanged is done. startScan 
actually -restarts- the scan! so -any- file modifications made by 
catalogmanager during the time CatalogManagerView::directoryChanged is run 
will likely cause an infinite loop, which seems to be what we're seeing.

why is it stopping the scan? my guess is that this is because elsewhere it 
calls kapp->processEvents, such as in buildDir which can be called from 
directoryChanged in the case of a change in a directory that catalogmanager 
doesn't have a record of yet, such as the auto4mate.cache dir it seems. my 
guess is that directoryChanged stops the scan so that it doesn't get new 
events from KDirWatch when the event loop re-enters before it's finished it's 
run of directoryChanged.

kapp->processEvents is evil, evil, evil and i would not be surprised in the 
least if this is the cause of the problems here, by indirectly causing 
directoryChanged to stop/start the scan on each entry.

so my guess is that something in one of the methods that gets called from 
directoryChanged triggers an update in KDirWatch which, when the scan is 
started again at the end of directoryChanged starts the whole process again 
until the stack is exhausted and the program simply dies. there are a lot of 
calls to QDir, QFileInfo, etc that get made out of directoryChanged, so i 
wouldn't be surprised if somewhere, somewhen such an update is triggered.

of course, if nothing causes KDirWatch to think something has updated then all 
is well and catalogmanager gets away with it. this may explain why it works 
with some methods and not others.

so ... my suggestion is to try this:

on a system where you can trigger the bug (seems easy to do so according to 
the bug report), comment out the kapp->processEvents in CatalogManagerView as 
well as the startScan/stopScan calls in directoryChanged and see if that 
makes the bug go away. if it does, that may well be a fine immediate solution 
(if not a perfect long term one). the downside is that the GUI of 
CatalogManagerView will freeze while the update happens.

that may not be a bad thing anyways since it looks from reading the code that 
all kinds of nasty things might happen if the user clicks around in 
catalogmanager while an update is happening due to those processEvents calls 
and a lack of guarding the UI at all =/

hth.

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

Full time KDE developer sponsored by Trolltech (http://www.trolltech.com)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20070406/fcb095cf/attachment.sig>