| Summary: | Locks up on searching in a large dir | ||
|---|---|---|---|
| Product: | [Applications] kfind | Reporter: | Dominique Devriese <devriese> |
| Component: | general | Assignee: | Eric Coquelle <coquelle> |
| Status: | RESOLVED FIXED | ||
| Severity: | crash | CC: | rdieter |
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Debian testing | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
| Attachments: |
Workaround to disable fam
patch for kdelibs/kio/kio/kdirwatch.cpp |
||
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 ? |
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