Version: (using KDE KDE 3.2.1) Installed from: Debian testing/unstable Packages When doing a search in a large dir ( my home dir ), KFind suddenly locks up. I have kept an eye on the process while it was running ( with lsof and gdb attach ), and it first is searching as it should, but then suddenly locks up. I think it occurs when I modify some file in my home dir. After the freeze, I have gdb attached to it, and I get this backtrace: #0 0x4113fa08 in write () from /lib/libpthread.so.0 #1 0x4126f950 in ?? () from /usr/lib/libfam.so.0 #2 0x4126ac63 in Client::writeToServer(char*, int) () from /usr/lib/libfam.so.0 #3 0x4126d9df in FAMClose () from /usr/lib/libfam.so.0 #4 0x4126da6a in FAMMonitorDirectory () from /usr/lib/libfam.so.0 #5 0x4022fe99 in KDirWatchPrivate::useFAM(KDirWatchPrivate::Entry*) (this=0x832e528, e=0x8ac6828) at kdirwatch.cpp:400 #6 0x40230f20 in KDirWatchPrivate::addEntry(KDirWatch*, QString const&, KDirWatchPrivate::Entry*, bool) (this=0x832e528, instance=0x8328798, _path=@0x83f6040, sub_entry=0x0, isDir=true) at kdirwatch.cpp:634 #7 0x40233dcb in KDirWatch::addDir(QString const&, bool, bool) (this=0x8328798, _path=@0x83f6040, watchFiles=true, recursive=false) at kdirwatch.cpp:1334 #8 0x08060e32 in KfindDlg::startSearch() (this=0xbffff960) at kfinddlg.cpp:143 #9 0x0805f95b in KfindDlg::qt_invoke(int, QUObject*) (this=0xbffff960, _id=84, _o=0xbffff020) at kfinddlg.moc:135 #10 0x40c43d0b in QObject::activate_signal(QConnectionList*, QUObject*) () from /usr/lib/libqt-mt.so.3 #11 0x40c43bab in QObject::activate_signal(int) () from /usr/lib/libqt-mt.so.3 #12 0x40570f63 in KDialogBase::user1Clicked() (this=0xbffff960) at kdialogbase.moc:245 #13 0x4056ebdd in KDialogBase::slotUser1() (this=0xbffff960) at kdialogbase.cpp:1198 #14 0x4057164a in KDialogBase::qt_invoke(int, QUObject*) (this=0xbffff960, _id=72, _o=0xbffff150) at kdialogbase.moc:358 #15 0x0805fa7f in KfindDlg::qt_invoke(int, QUObject*) (this=0xbffff960, _id=72, _o=0xbffff150) at kfinddlg.moc:145 #16 0x40c43d0b in QObject::activate_signal(QConnectionList*, QUObject*) () from /usr/lib/libqt-mt.so.3 #17 0x40c43bab in QObject::activate_signal(int) () from /usr/lib/libqt-mt.so.3 #18 0x40f9822f in QButton::clicked() () from /usr/lib/libqt-mt.so.3 #19 0x40cd6bfd in QButton::mouseReleaseEvent(QMouseEvent*) () from /usr/lib/libqt-mt.so.3 #20 0x40c7b6b7 in QWidget::event(QEvent*) () from /usr/lib/libqt-mt.so.3 #21 0x40be0ba3 in QApplication::internalNotify(QObject*, QEvent*) () from /usr/lib/libqt-mt.so.3 #22 0x40be03cb in QApplication::notify(QObject*, QEvent*) () from /usr/lib/libqt-mt.so.3 #23 0x4075d424 in KApplication::notify(QObject*, QEvent*) (this=0xbffffab0, receiver=0x8168c80, event=0xbffff540) at kapplication.cpp:506 #24 0x40b76442 in QApplication::sendSpontaneousEvent(QObject*, QEvent*) () from /usr/lib/libqt-mt.so.3 #25 0x40b6fadb in QETWidget::translateMouseEvent(_XEvent const*) () from /usr/lib/libqt-mt.so.3 #26 0x40b6d7c7 in QApplication::x11ProcessEvent(_XEvent*) () from /usr/lib/libqt-mt.so.3 #27 0x40b87697 in QEventLoop::processEvents(unsigned) () from /usr/lib/libqt-mt.so.3 #28 0x40bf6a75 in QEventLoop::enterLoop() () from /usr/lib/libqt-mt.so.3 #29 0x40be0d6b in QApplication::enter_loop() () from /usr/lib/libqt-mt.so.3 #30 0x40ddbc02 in QDialog::exec() () from /usr/lib/libqt-mt.so.3 #31 0x08062007 in main (argc=1, argv=0xbffffc14) at main.cpp:66 Also note the following: (gdb) down 8 #8 0x08060e32 in KfindDlg::startSearch() (this=0xbffff960) at kfinddlg.cpp:143 143 in kfinddlg.cpp (gdb) printqstring (*it) /home/domi/downloads/lm-sensors-2.8.1/prog/tellerstats (gdb) When I leave the process running for a while, and then try again, the same string is still in (*it). So there must be some sort of lockup further down the stack. I hope you can do something with this info. thanks domi
Created attachment 6552 [details] Workaround to disable fam I can't reproduce the problem with this patch applied. I'm on FC1 with kdebase-3.2.3.
Created attachment 9175 [details] patch for kdelibs/kio/kio/kdirwatch.cpp Dominique: Can you still reproduce this? Can you try and see if the attached patch helps?
Waldo Bastian writes: > Dominique: Can you still reproduce this? Can you try and see if the > attached patch helps? Not in the near future, I have exams, and am not running KDE HEAD. sorry domi
CVS commit by waba: Disable recursively watching for updates BUG: 68220 BUG: 77854 BUG: 77846 BUG: 79512 BUG: 85802 M +13 -0 kfinddlg.cpp 1.25 --- kdebase/kfind/kfinddlg.cpp #1.24:1.25 @@ -127,4 +127,16 @@ void KfindDlg::startSearch() dirwatch->addDir(query->url().path(),true); +#if 0 + // waba: Watching for updates is disabled for now because even with FAM it causes too + // much problems. See BR68220, BR77854, BR77846, BR79512 and BR85802 + // There are 3 problems: + // 1) addDir() keeps looping on recursive symlinks + // 2) addDir() scans all subdirectories, so it basically does the same as the process that + // is started by KQuery but in-process, undoing the advantages of using a seperate find process + // A solution could be to let KQuery emit all the directories it has searched in. + // Either way, putting dirwatchers on a whole file system is probably just too much. + // 3) FAM has a tendency to deadlock with so many files (See BR77854) This has hopefully + // been fixed in KDirWatch, but that has not yet been confirmed. + //Getting a list of all subdirs if(tabWidget->isSearchRecursive() && (dirwatch->internalMethod() == KDirWatch::FAM)) @@ -134,4 +146,5 @@ void KfindDlg::startSearch() dirwatch->addDir(*it,true); } +#endif win->beginSearch(query->url());
Waldo, I assume your comment #4 modifcation Obsoletes the patch in comment #2 ?