Version: KFind: 2.0, KDE: 3.1.93 (CVS >= 20031111) (using KDE Devel) Installed from: Compiled sources Compiler: gcc version 3.2.2 OS: Linux (i686) release 2.6.0-test6 If I'm running KFind standalone (not embedded into konqueror), I can make it lock up just doing a few trivial searches. For instance, searching through the Quanta source looking for files named "edit*" locked up. I might be imagining it, but it appears to lock up more often if you press the find button instead of just hitting enter in the "Named:" lineedit. I realize this isn't the best of reproduction descriptions, but from where I sit, the question is more of what can I do to NOT make it lock up. (I couldn't reproduce this when running the embedded find dialog in konqueror. There i just works, and fast. :) )
"kill -SIGSEGV <processid>" the process and post the backtrace please.
The backtrace appears useless to me: [New Thread 16384 (LWP 20216)] 0x4126b359 in waitpid () from /lib/libpthread.so.0 #0 0x4126b359 in waitpid () from /lib/libpthread.so.0 #1 0x407b0a50 in KCrash::defaultCrashHandler(int) () from /opt/kde/lib/libkdecore.so.4 #2 0x4126a17c in __pthread_sighandler () from /lib/libpthread.so.0 Attaching with GDB is a little more promising: (gdb) bt #0 0x4126a2d8 in write () from /lib/libpthread.so.0 #1 0x412cf8ec in FAMDebugLevel () from /usr/lib/libfam.so.0 It does appear FAM related. If I stop FAM I cannot reproduce the problem, but as soon as I start it again, the freeze is back. I guess this means it might be a distro, or even system, issue.
Thanks for the tip on fam - I was able to finally make it work without hang on MDK10 (now community; KDE3.2, kernel2.6.3) which has this problem on my dual celeron: http://qa.mandrakesoft.com/show_bug.cgi?id=8079
I'm using 3.3_alpha1 and the problem is still there, as it was is kde 3.2. I'm running gentoo. kfind is UNUSABLE. Just try to find a file in /usr. As soon as it starts the seach it freezes there, but the HD is working hard. After a few minutes I kill it. Fortunately I have the gnome seach tool to get my searches done.
The find tool is completely unusable for me too. It locks up for me as soon as I hit 'find', no matter what options I input. I run Mandrake 10.0 with kernel 2.6.3 and KDE 3.2 just updated to 3.2.3 (which caused more problems not related) but didn't help. I just use the console find.
Using KDE 3.3.0 I can reproduce this 100% of the time #kfind and search for ANYTHING and it locks up hard. # killall famd and try again and Kfind works fine.
I have Mandrake 10.1, kernel 2.6.8, and I grabbed and compiled KDE 3.3.2 from konstruct/kde.org, and I am having the same kfind problems. If I try and do ANY search starting from '/' (and not the default '/home/<USER>', kfind locks up. I did do a 'kill -SIGV <processid>', as I have seen this requested: Using host libthread_db library "/lib/tls/libthread_db.so.1". [Thread debugging using libthread_db enabled] [New Thread 1096763648 (LWP 11540)] [KCrash handler] #7 0x4153e03c in memcpy () from /lib/tls/libc.so.6 #8 0x40f1079d in QString::operator+= () from /usr/lib/qt3/lib/libqt-mt.so.3 #9 0x23ec889a in ?? () #10 0x23f9ece8 in ?? () #11 0x00000234 in ?? () #12 0x01ff6f88 in ?? () #13 0x4153002f in _IO_file_fopen () from /lib/tls/libc.so.6 #14 0xbfff70b0 in ?? () #15 0xbfff7150 in ?? () #16 0x40ee588d in QDir::init () from /usr/lib/qt3/lib/libqt-mt.so.3 #17 0x2493fe30 in ?? () #18 0xbfff70b0 in ?? () #19 0xffffffff in ?? () #20 0x41080aa8 in ?? () from /usr/lib/qt3/lib/libqt-mt.so.3 #21 0x23e66458 in ?? () #22 0x00000287 in ?? () #23 0x2493fee0 in ?? () #24 0x41080aa8 in ?? () from /usr/lib/qt3/lib/libqt-mt.so.3 #25 0xbfff7150 in ?? () #26 0x08074b9c in QChar::null () #27 0xbfff70f0 in ?? () #28 0x40ee7684 in QDir::QDir () from /usr/lib/qt3/lib/libqt-mt.so.3 #29 0xbfff70f0 in ?? () #30 0xbfff7180 in ?? () #31 0x00000006 in ?? () #32 0x40f1079d in QString::operator+= () from /usr/lib/qt3/lib/libqt-mt.so.3 #33 0x24a91aae in ?? () #34 0x24577e68 in ?? () #35 0x00000006 in ?? () #36 0xbfff7154 in ?? () #37 0x41536dda in free () from /lib/tls/libc.so.6
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());