Bug 77846 - UI freezes while searching
Summary: UI freezes while searching
Status: RESOLVED FIXED
Alias: None
Product: kfind
Classification: Applications
Component: general (show other bugs)
Version: unspecified
Platform: Debian testing Linux
: NOR wishlist with 105 votes (vote)
Target Milestone: ---
Assignee: Eric Coquelle
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-03-17 16:43 UTC by Dominique Devriese
Modified: 2006-04-27 11:03 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Dominique Devriese 2004-03-17 16:43:13 UTC
Version:            (using KDE KDE 3.2.1)
Installed from:    Debian testing/unstable Packages

Note: this is a forward of the following Debian bug report:
http://bugs.debian.org/238417

When doing a content-based search in a large directory ( e.g. /usr ), kfind's UI freezes while the search is going on.  This should be done in a separate thread or process.
Comment 1 Aaron Johnson 2004-04-19 21:25:30 UTC
I believe that http://bugs.kde.org/show_bug.cgi?id=79512 is a duplicate of this.
Comment 2 Aaron Johnson 2004-08-19 21:32:07 UTC
I believe that http://bugs.kde.org/show_bug.cgi?id=79512 is a duplicate of this bug.
Comment 3 Aaron Johnson 2004-08-19 21:42:13 UTC
Sorry for the duplicate post. Just to clarify, this bug is for when Kfind is searching large folders with the "include subfolders" checked. The UI freezes and never comes back, which means Kfind has to be killed. This bug is still evident in KDE 3.3.
Comment 4 Ben Smith 2004-08-20 18:29:45 UTC
That may be what the Debian bug report says, but it isn't what this report says, and the suggested solution (starting a separate thread) won't necessarily fix bug 79512.

Even when functioning normally (ie, not locking up), the kfind UI fails to update until it receives the results from the find process.  This is especially evident when searching in large directories.  This behaviour is a separate bug imho.

If someone wants to mark this a duplicate of bug 79512 I'll be happy to open a new bug for the (less important) 'UI-fails-to-update' behaviour.
Comment 5 Adeodato Simó 2004-08-21 01:16:40 UTC
* Ben Burton [Wed, 17 Mar 2004 10:43:11 +1100]:

> > I am trying to use kfind to seach /usr which, at 1.7GB, is one of the 
> > larger directories in my filesystem.  I have "include subfolders" 
> > checked.  It seems to work alright for most directories, but when I ask 
> > it to search a large one, it appears to hang.

> I've just tested this and certainly kfind is not refreshing itself while
> the search takes place.  At the very least (given that find operations
> can be slow), kfind should have a separate thread running that updates
> the GUI (and preferably gives some kind of progress reporting as well).

  I can't reproduce now with KFind from KDE 3.3. I've search in /usr for
  files which contain the text "hello". (File Type: All Files & Folders,
  Include subfolders checked.)

  the UI does not freeze, and the resutls panel is incrementally
  updated. the "Stop" button works at any stage of the search.

  can anybody confirm?

Comment 6 Roman Pearce 2004-08-23 11:04:08 UTC
I can confirm this in KDE 3.3 on Gentoo.  A large search (not using the index) hogs the UI completely.
Comment 7 Rinse De Vries 2004-08-26 10:16:53 UTC
I use KDE 3.3 as well, and the GUI of kfind does not block during a search. During a large search (searching vor *kde* in /) the guis is still accessible, all the buttons work, etc..

So I guess this bug has been resolved.
Comment 8 Aaron Johnson 2004-08-29 06:10:04 UTC
I have KDE on two different machines. What is strange is that one machine (which is a fully updated Debian Sid machine), the bug shows up. On my home machine, which does not have completely updated Debian Sid files, the bug does not occur. The bug on the work machine is as follows: when searching large directories with "include subfolders", kfind freezes. When "include subfolders" is not selected, it does not freeze. The bug first showed up in KDE 3.2, and continues in 3.3. Is there any way I can help debug the problem? Unfortunately, my work machine is behind a firewall so having someone do a remote desktop connection will not work. So if someone can give me something to look for, I can do my best to get the information needed.
Comment 9 Christopher Bolin 2004-10-09 07:16:37 UTC
For those having this problem - kill famd and try again.  IT works for me every time.

Using KDE 3.3
Comment 10 Aaron Johnson 2004-10-11 16:40:20 UTC
Killing famd worked for me. Now to find out why it is causing problems with kfind. I've remove fam from my debian files, because I can't determine its importance and none of the other programs seem to depend on it. I guess if I need it later, I can reinstall it.
Comment 11 Waldo Bastian 2005-01-25 18:48:05 UTC
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());