Bug 41514 - KMail freezes the UI when checking for new mail
Summary: KMail freezes the UI when checking for new mail
Status: RESOLVED FIXED
Alias: None
Product: kmail
Classification: Unclassified
Component: general (show other bugs)
Version: SVN trunk (KDE 4)
Platform: RedHat RPMs Linux
: NOR normal with 4370 votes (vote)
Target Milestone: ---
Assignee: kdepim bugs
URL:
Keywords: triaged
: 37054 37149 46654 52192 61170 62006 63559 77957 81458 89166 90043 91286 96500 98336 121207 122164 123763 136615 137546 141852 144091 147928 159610 215154 274004 (view as bug list)
Depends on:
Blocks:
 
Reported: 2002-04-23 10:33 UTC by A T Somers
Modified: 2011-09-29 13:38 UTC (History)
75 users (show)

See Also:
Latest Commit:
Version Fixed In: 4.8.0


Attachments
Test patch to rule out sorting. (2.14 KB, patch)
2003-06-24 01:02 UTC, Roger Larsson
Details
Filter to show lock in pipe (77 bytes, text/plain)
2005-06-13 01:16 UTC, Matthias Wieser
Details
Idea to solve that lock - ask for feedback (858 bytes, patch)
2005-06-13 01:22 UTC, Matthias Wieser
Details

Note You need to log in before you can comment on or make changes to this bug.
Description A T Somers 2002-04-23 10:23:18 UTC
(*** This bug was imported into bugs.kde.org ***)

Package:           kmail
Version:           1.4 (using KDE 3.0.0 )
Severity:          wishlist
Installed from:    Red Hat Linux 7.2.92
Compiler:          gcc version 2.96 20000731 (Red Hat Linux 7.2 2.96-109)
OS:                Linux (i686) release 2.4.7-10
OS/Compiler notes: 

KMail currently freezes the UI when checking for new mail. This is very irritating when I'm typing a message and new mail is automaticly being fetched. As this sometimes may take awhile (due to filtering with spamassassin) this may block typing for several seconds. I think it would make sence to make things like checking mail run in a seperate thread so it does not interfere with the normal use of the application.

(Submitted via bugs.kde.org)
(Called from KBugReport dialog)
Comment 1 Marc Mutz 2002-04-23 13:59:39 UTC
retitle KMail freezes the UI when checking for new mail
quit

On Tuesday 23 April 2002 12:23 a.t.somers@student.utwente.nl wrote:
<snip>
> KMail currently freezes the UI when checking for new mail.
<snip>

Never! Threading is for losers. QTimer rulez ;-)

Marc

--=20
Marc Mutz <mutz@kde.org>
Comment 2 Roger Larsson 2002-10-30 21:46:37 UTC
I have seen this too - but I cant reproduce it fully.        
I noticed that it did not freeze for the complete download, only close to finished         
(i.e. not 100% more like 94%, whole test message 84,7 kB)    
It might freeze slightly for each mail received. 
I have not been able to provoke kmail to get the several seconds freezes I have seen...        
         
Other things that might be related:         
* I had a folder open (linux-kernel 25840 mails)        
* It might be that it freeze only on mail arriving to that folder       
* My network is unreliable (WiFi - radio), what happens if a network operation  
  takes much longer time than expected?      
Comment 3 Julian Rockey 2002-12-15 14:29:23 UTC
My KMail (from 3_1_BRANCH, gcc 3.2 compiled, on Linux 2.4.19-ck9) does this 
consistently - for each POP3 account it checks, the UI freezes a while. I supposed it's 
more noticeable as I'm using a 56k dialup. 
 
I seem to remember it started happening when I moved from Mandrake to an LFS 
compiled system. Could it be related to another package KMail depends on? 
 
Comment 4 Roger Larsson 2003-03-08 00:48:27 UTC
It still freezes. 
I think it is related to new mails arriving in the folder I am viewing. 
The folder (linux-kernel) is quite big (18720 messages, 217 MB) 
Comment 5 Roger Larsson 2003-03-28 03:44:02 UTC
OK, worse freezes than ever (>10s). But there is hope... 
I think that it is related to: 
*  KeramikStyle/KStyle 
*  Threaded message folder with LOTS of messages 
=> when a new mail arrives the folder have to be repainted. 
Repainting in this case involves lots of complex sorting. 
Heap based... I found out that it does TWO non file based 
mmap2 with size 389120, then freezes, and munmap both. 
This made me look closer on sorting issues. There I found 
this: 
 
int KFolderTreeItem::countUnreadRecursive() 
{ 
  int count = (mUnread > 0) ? mUnread : 0; 
 
  // sorts! not necessary for counting items 
  for ( QListViewItem *item = firstChild() ; 
      item ; item = item->nextSibling() ) 
  { 
    count += static_cast<KFolderTreeItem*>(item)->countUnreadRecursive(); 
  } 
 
  return count; 
} 
 
I think it should use child() instead just like in KMFolder::countUnreadRecursive 
Comment 6 Roger Larsson 2003-03-28 03:55:15 UTC
Noticed that this bug was marked as a wishlist item... (>10 s is not acceptable...) 
I was considering severity Major but since not that many can be hit by it I settle 
for Normal 
Comment 7 Roger Larsson 2003-03-28 08:32:57 UTC
Bug in my bug report: The folder is not threaded 
 
More data: The folder contains 24236 messages! (linux-kernel) 
 
If I thread it it the responsibility improves quite a bit. (Fewer elements to sort?) 
I suspect that it is something in the sorting. (Data to big to fit in cache? Expensive 
comparisons due to i18n...) 
Comment 8 Carsten Burghardt 2003-03-29 12:38:05 UTC
Subject: Re:  KMail freezes the UI when checking for new mail

On Friday 28 March 2003 03:44, Roger Larsson wrote:
> int KFolderTreeItem::countUnreadRecursive()
> {
>   int count = (mUnread > 0) ? mUnread : 0;
>
>   // sorts! not necessary for counting items
>   for ( QListViewItem *item = firstChild() ;
>       item ; item = item->nextSibling() )
>   {
>     count += static_cast<KFolderTreeItem*>(item)->countUnreadRecursive();
>   }
>
>   return count;
> }
>
> I think it should use child() instead just like in
> KMFolder::countUnreadRecursive

The above code does not sort the items (according to the doc) and there is no 
child() in QListViewItem.

Comment 9 Roger Larsson 2003-03-29 16:37:27 UTC
Subject: Re:  KMail freezes the UI when checking for new mail

(Mueller and Faure cc'd since you have been working in this code...
 KFolderTreeItem::countUnreadRecursive() calls firstChild - firstChild sorts
 )

But firstChild does enforceSortOrder()

3805    QListViewItem* QListViewItem::firstChild() const
3806    {
3807        enforceSortOrder();
3808        return childItem;
3809    }

According to the documentation it should not - sorting should be done only 
when displaying a list...

(enforceSortOrder helps since it first checks if sorting is needed)

Should firstChild sort?

Comment 10 Roger Larsson 2003-03-29 21:05:41 UTC
Subject: QListView sorting inefficiancy? (Was: Re:  KMail freezes the UI when checking for new mail)

KDE bug link: http://bugs.kde.org/show_bug.cgi?id=41514

OK, I have looked at the qt sorting - it can be improved...
At least I found the reason why I get two mmaps (really mallocs) of
389120 bytes... (note the stall is in between those allocs - and that is
the sorting algorithm)

OK, I have I have 24236 messages to sort. QListViewItem::sortChildItems
creates an array (line 1302) and copies a pointer to the items into that
array.
If the number of items are big the array becomes big too (16 bytes per item).
In my case it will trash my CPU cache (256 kB)

1282    void QListViewItem::sortChildItems( int column, bool ascending )
1283    {
1284        // we try HARD not to sort.  if we're already sorted, don't.
1285        if ( column == (int)lsc && ascending == (bool)lso )
1286            return;
1287
1288        if ( column < 0 )
1289            return;
1290
1291        lsc = column;
1292        lso = ascending;
1293
1294        const int nColumns = listView()->columns();
1295
1296        // and don't sort if we already have the right sorting order
1297        if ( column > nColumns || childItem == 0 || childItem->siblingItem 
== 0 )
1298            return;
1299
1300        // make an array for qHeapSort()
1301        QListViewPrivate::SortableItem * siblings
1302            = new QListViewPrivate::SortableItem[nChildren];
1303        QListViewItem * s = childItem;
1304        int i = 0;
1305        while ( s && i < nChildren ) {
1306            siblings[i].numCols = nColumns;
1307            siblings[i].col = column;
1308            siblings[i].asc = ascending;
1309            siblings[i].item = s;
1310            s = s->siblingItem;
1311            i++;
1312        }
1313
1314        // and sort it.
1315        qHeapSort( siblings, siblings + nChildren );
1316
1317        // build the linked list of siblings, in the appropriate
1318        // direction, and finally set this->childItem to the new top
1319        // child.
1320        if ( ascending ) {
1321            for( i = 0; i < nChildren - 1; i++ )
1322                siblings[i].item->siblingItem = siblings[i+1].item;
1323            siblings[nChildren-1].item->siblingItem = 0;
1324            childItem = siblings[0].item;
1325        } else {
1326            for( i = nChildren - 1; i > 0; i-- )
1327                siblings[i].item->siblingItem = siblings[i-1].item;
1328            siblings[0].item->siblingItem = 0;
1329            childItem = siblings[nChildren-1].item;
1330        }
1331        for ( i = 0; i < nChildren; i++ ) {
1332            if ( siblings[i].item->isOpen() )
1333                siblings[i].item->sort();
1334        }
1335        delete[] siblings;
1336    }

qHeapSort counts the number of items, known a moment before...

../include/qtl.h:253
249     template <class InputIterator>
250     Q_INLINE_TEMPLATES void qHeapSort( InputIterator b, InputIterator e )
251     {
252         // Empty ?
253         if ( b == e )
254             return;
255
256         // How many entries have to be sorted ?
257         InputIterator it = b;
258         uint n = 0;
259         while ( it != e ) {
260             ++n;
261             ++it;
262         }
263
264         // The second last parameter is a hack to retrieve the value type
265         // Do the real sorting here
266         qHeapSortHelper( b, e, *b, n );
267     }

qHeapSortHelper won't use the created sort array - it creates another one...
(line 223, cache lost again...)

../include/qtl.h:222
218     template <class InputIterator, class Value>
219     Q_INLINE_TEMPLATES void qHeapSortHelper( InputIterator b, 
InputIterator e, Value, uint n )
220     {
221         // Create the heap
222         InputIterator insert = b;
223         Value* realheap = new Value[n];
224         // Wow, what a fake. But I want the heap to be indexed as 1...n
225         Value* heap = realheap - 1;
226         int size = 0;
227         for( ; insert != e; ++insert ) {
228             heap[++size] = *insert;
229             int i = size;
230             while( i > 1 && heap[i] < heap[i / 2] ) {
231                 qSwap( heap[i], heap[i / 2] );
232                 i /= 2;
233             }
234         }

Ordinary heap sort - but the comparasions will be extremely expensive [it
looks cheap here...] since the cache will be trashed over and over... :-(

Observations:
* the data to sort is most likely partially sorted already, only a one or a
  few messages have been added.
* sorting will be done to my linux-kernel folder whenever a message arrives
  (insertItem => Unsorted) and I have that folder open => sorting)

Possible improvements:
* split the children in one sorted and one unsorted.
	* insertItem puts the new item on an unsorted list.
* add info about partially sorted (possibly in several dimensions/columns...)
* when sorting is needed, 
	* sort the new data (it is often partially sorted too. Like arrival/insertion
	  order) - qHeapSort is probably OK, but I prefere merge sort.
	* merge the old and the new items, list merge.
* the double allocation that is done today should be removed,
	* sortChildItems could call qHeapSortHelper directly.
	* qHeapSortHelper can sort in place

Comment 11 A T Somers 2003-04-04 12:48:30 UTC
I am seriously doubting that the sorting is the real problem in my case. The real 
problem lies in the filters: I make use of Spamassassin (spamd/spamc combination) 
to filter out the masses of spam I receive. I accept this takes time, but I don't like it 
that I can't use KMail to view allready received messages while other messages are 
drippling in. The screen isn't even redrawn if I switch back and forth between 
applications! I really think this should be done in a better way, possibly using a 
thread for the mailfetching/filtering. 
Comment 12 Roger Larsson 2003-04-23 21:12:12 UTC
My problem is in the sorting part. Between the new (mmap) and free. 
* The amount of data to sort is big. 
* Each comparision requires complex translations to localized sort order. 
Try to add debug traces to verify - if your problem is not related to sorting 
another bug should be opened. 
 
One easy speed improvement is to optimize when sort order is reversed. 
 
1285 if ( column == (int)lsc && ascending == (bool)lso )  
1286 return; 
 
if ( column == (int)lsc) 
 if (ascending == (bool)lso )  
	return; 
  else { 
	reverse(); // reverses list and negates ascending... 
	return; 
 } 
 
I have been thinking about a radix sort implementation, and now Jamie 
has started with one... One of the biggest problems is to keep 
binary compatibility. 
 
 
Comment 13 Ingo Klöcker 2003-05-29 00:30:44 UTC
*** Bug 52192 has been marked as a duplicate of this bug. ***
Comment 14 wturkal 2003-06-09 05:42:13 UTC
I believe that this has to do with some form of blocking when running the 
filters that use a pipe like spamd and whatnot. There needs to be some way to 
background the filter piping via threads or some other clever mechanism. 
Comment 15 Ferdinand Gassauer 2003-06-09 21:11:35 UTC
Subject: Re:  KMail freezes the UI when checking for new mail

On Monday 09 June 2003 05:42, you wrote:
> ------- You are receiving this mail because: -------
> You are on the CC list for the bug, or are watching someone who is.
>
> http://bugs.kde.org/show_bug.cgi?id=41514
>
>
>
>
> ------- Additional Comments From wturkal@cbu.edu  2003-06-09 05:42 -------
> I believe that this has to do with some form of blocking when running the
> filters that use a pipe like spamd and whatnot. There needs to be some way
> to background the filter piping via threads or some other clever mechanism.
Yes it's spamd or spamc causing the blocking.
IMHO this should be solved for 3.2, as it also blocks kmail-composer during 
writing.
Comment 16 Malte S. Stretz 2003-06-09 21:36:37 UTC
On bug 52192, which got marked as a dup of this one, I suggested making the 
filters run asynchronously (ie. in a separate thread). I also tried to implement this 
but it's too complex for me... 
Comment 17 wturkal 2003-06-10 15:44:19 UTC
Subject: Re:  KMail freezes the UI when checking for new mail

Maybe it should not be just the filters. The whole of the check mail process 
would probably be a good candidate for separation into its own thread.

Someone suggested QTimer, but I am not sure if QTimer is a good fit as the 
operation is not an easily divisible problem. Each message must be processed 
atomically, and some messages could be big enough to stall Kmail on their 
own. I think a thread for checking the mail (including running filters) would 
alleviate the UI lockup that we are experiencing.
Comment 18 Tim Middleton 2003-06-18 13:49:54 UTC
I want to add my agreement to many of the comments that it is both mail checking
and filtering which cause blocks in my experience (and other functions such as
expiry/compact). All of these things should be broken out into seperate
processes or threads that do not affect the main UI, if possible. Even message
composing is affected. It really makes Kmail look bad. I'm glad to see this is
getting attention here.

I'm migrating from The Bat on windows, and every function in The Bat is smooth
as silk. The Bat has a "connection center" which pops up (optionally) and gives
an overview on the progress of all active connections and download/upload
progress(es). Very nice... never affects the rest of the program even when
downloading megs and megs of mail with dozens and dozens of filters.

Comment 19 Roger Larsson 2003-06-24 01:02:13 UTC
Created attachment 1874 [details]
Test patch to rule out sorting.

I wanted to create a patch that disabled sorting in kmheaders, to be able to
rule out sorting time as a cause.

Why: because I feel that I get longer stalls when I have a big folder open.

First approach added enforceSortOrder but for some reason I got into
QListViewItem::enforceSortOrder anyway - I think this is because of
the Root class in QListViewItem. KMHeaders does not inherit it...

Anyway - found out a simpler way: set mSortCol to -1 at the right moment.
This will make the folder unsorted from opening it until selecting a column.
(This should be enough for the test).
Comment 20 Roger Larsson 2003-06-25 02:09:45 UTC
It kind of works, the long stalls are gone (IMHO) 
There are still short stalls. People with faster computers 
and slower net might not find this true... 
 
This version is short and recompiles quickly - please test. 
(The folder will not be resorted until you select a column) 
 
diff -u -3 -p -r1.512 kmheaders.cpp 
--- kmheaders.cpp       11 Jun 2003 11:06:30 -0000      1.512 
+++ kmheaders.cpp       24 Jun 2003 23:58:12 -0000 
@@ -755,6 +755,8 @@ void KMHeaders::readFolderConfig (void) 
   mSortDescending = (mSortCol < 0); 
   mSortCol = abs(mSortCol) - 1; 
 
+  mSortCol = -1; 
+ 
   mTopItem = config->readNumEntry("Top", 0); 
   mCurrentItem = config->readNumEntry("Current", 0); 
 
Comment 21 Ingo Klöcker 2003-06-26 01:19:18 UTC
Subject: Re:  KMail freezes the UI when checking for new mail

On Wednesday 25 June 2003 02:09, Roger Larsson wrote:
> It kind of works, the long stalls are gone (IMHO)
> There are still short stalls. People with faster computers
> and slower net might not find this true...

Hmm, switching to my kde-devel folder (26k messages) goes down from 
about 9 seconds to 5-6 seconds. It's an improvement but not that 
radical. FWIW, I'm using threading and sort by Date (descending, i. e. 
the first message is the most recent message).

Comment 22 wturkal 2003-06-26 03:55:41 UTC
This is not fixing the root of the problem...I keep my folders with few (<200) 
messages in them. Most I empty every day. The stalling that I am talking about 
comes from piping messages through external filters and that operation 
blocking. 
Comment 23 Roger Larsson 2003-06-26 08:33:12 UTC
Subject: Re:  KMail freezes the UI when checking for new mail

Ingo - Try it unthreaded. On the other hand 3 s for adding in a few messages
into an already sorted folder... It should not take seconds...

My sorting took over 10 s... (933MHz PIII, 256MB) and the stall is now down to
under one second.

I use kmails filter on headers - noting more, do you also use external filters
like wturkal?
My internet connection is ADSL - 0.5 Mb/s

Comment 24 Ferdinand Gassauer 2003-06-26 08:52:22 UTC
Subject: Re:  KMail freezes the UI when checking for new mail

On Thursday 26 June 2003 08:33, you wrote:

IMHO using spamassassin (2.52) still stalls kmail.

FYI
I have no performance problems opening folders - I use maildir format
every folder (+1000 mails) opens well below 1 second, sorting by date + 
threading.

Comment 25 Roger Larsson 2003-06-26 09:35:24 UTC
Subject: Re:  KMail freezes the UI when checking for new mail

> I have no performance problems opening folders - I use maildir format
> every folder (+1000 mails) opens well below 1 second, sorting by date +
> threading.

I guess I have to explain the situation again.
* Opening folders is not a problem since it reads the sort index from file
  - no sorting necessary.
* Sorting a folder by klicking on a column is not a big problem since you
  don't do it regulary.
My sorting problem is that
* On (every) new message that arrives in an Open folder. The folder has
  to be resorted and it is resorted as if it was completely unsorted before...
  This takes memory and time that will hit you hard, especially if you have
  something memory and CPU consuming going on - like a compilation.
  - It is better to sort the new messages and then merge them into the already
  sorted.
* The sorting is not optimal for the task (hidden details)
  A string key (that is cached) is created - good.
  Comparitions of those strings are done with locale (for names?) - not good.
But the root of the problem is the same - kmail is not threaded to do heavy
work.

Comment 26 A T Somers 2003-06-26 09:37:16 UTC
Subject: Re:  KMail freezes the UI when checking for new mail

I confirm. Filtering via SpamAssassin (2.60) can stall for a _long_ time (I'm 
talking about several minutes of freezing while fetching mail), opening a 
mailbox with several thousends of messages is no problem at all.

Andr
Comment 27 Ferdinand Gassauer 2003-06-26 10:02:17 UTC
Subject: Re:  KMail freezes the UI when checking for new mail

On Thursday 26 June 2003 09:35, you wrote:
snip...
> My sorting problem is that
> * On (every) new message that arrives in an Open folder. The folder has
>   to be resorted and it is resorted as if it was completely unsorted
> before... This takes memory and time that will hit you hard, especially if
> you have something memory and CPU consuming going on - like a compilation.
Hmm I always run compilation with "nice" to allow as much as possible 
resources to other time critical tasks.
And it does not slow down compilation noticably.

Comment 28 Ingo Klöcker 2003-07-14 02:06:07 UTC
*** Bug 61170 has been marked as a duplicate of this bug. ***
Comment 29 Tom Chance 2003-07-25 01:12:33 UTC
I also experience long freezes when piping mail through Spam Assassin. This needs to be 
tackled by a proper threaded approach to fetching and piping mail; relying on fast download 
and computer speeds isn't a solution, it's ignoring the problem. 
Comment 30 Dominik Stadler 2003-07-25 09:57:56 UTC
Anybody thinking about solving this bug via threading, have a look at knode.

There a job-queue is used that receives all the different donwload-jobs that are
caused by clicking on groups, clicking on articles or requesting a refresh of
all groups of an account. A second thread executes jobs on the queue one-by-one. 

This could be used the same way for kmail.
Comment 31 Malte S. Stretz 2003-08-02 15:00:11 UTC
*** Bug 62006 has been marked as a duplicate of this bug. ***
Comment 32 Ingo Klöcker 2003-08-18 00:54:31 UTC
*** Bug 62849 has been marked as a duplicate of this bug. ***
Comment 33 A T Somers 2003-08-18 07:34:18 UTC
Subject: Re:  kmail freezes if filter-triggered process takes forever

Hi Ingo,

Why was this bug marked a duplicate? I am very well aware of bug 41514 (I 
reported it!), but this is a different problem!
Bug 41514 is about KMail freezing the GUI if checking for mail. For a large 
part (in my case) this is due to the filtering of messages through 
Spamassassin. Because of the nature of this filter (pipe through), KMail must 
wait for the process to complete. Even if this problem were to be addressed 
by spawning a thread to do the mailchecking and filtering, you have not 
solved the problem I reported with this (62849) bug: waiting to eternity on a 
process that can be fire-and-forget. I think this is a lot easier to solve 
than bug 41514 in fact, by not letting KMail wait for processes to finish 
who's output is not needed. I think fixing 41514 but not 62849 would cause 
big trouble. Now you don't have a whole application that's frozen (and that 
the user can notice and find a cause for, like I did), but just a background 
thread. The user will never notice the problem, but meanwhile all 
mailfetching and filtering is blocked...

Andr
Comment 34 Ingo Klöcker 2003-09-01 17:08:19 UTC
*** Bug 63559 has been marked as a duplicate of this bug. ***
Comment 35 ralphdewitt 2003-09-01 17:53:53 UTC
Not only does Kmail 1.5.3 hang while running filters and spamassin when recieveing 
new mail, but it also hangs while trying to download and recieve gpg signatures. This 
hang requires the processe to be killed if the gpg signature cannot be retrieved, 
because the sender has never upload to a public server but maintains it privately. 
Both types of hangs are unnecessary and come very close to making kmail 
unuseable. It is also unaccetable that this bug has been around for so long and is 
listed as new and wishlist. This bug which casuse hang that needs the processe to 
be killed is far from a wishlist. It is a major bug, that needs fixing now. 
Comment 36 Julien Ponge 2003-09-07 21:41:22 UTC
I have noticed this problem since I pipe my incoming email through 
SpamAssassin. The UI gets frozen for a *long* time and this is not acceptable. 
It's even worse when it freezes while you're typing a message because it 
fetches the mails in the background. 
 
I think that the whole emails download process should be done in a separate 
thread. 
Comment 37 Malte S. Stretz 2003-09-20 23:25:48 UTC
*** Bug 46654 has been marked as a duplicate of this bug. ***
Comment 38 Geoffrey Clements 2003-10-09 14:10:32 UTC
Just a note to say that I see this problem when filtering through spamassassin 
(spamc) although the latest version of SA (2.60) seems to have reduced the 
effect (by being quicker I guess).
Comment 39 Tristan Miller 2003-10-26 13:32:33 UTC
This bug became a major problem for me with the recent glut of Windows worms.  Since I filter all mail through SpamAssassin, sometimes KMail would block for an hour or more when retrieving several days' worth of new mail.

For those suffering a similar problem, I've found that a workaround is to use fetchmail and procmail to pre-fetch and spam-assassinate mail for KMail to pick up from a local mail folder in /var/spool/mail.  This way KMail can retrieve mail as it's filtered rather than in one huge blocking operation.
Comment 40 Roland Lezuo 2003-12-11 12:16:19 UTC
I have this ug with KDE 3.2.0_beta1 and beta2 I did not have this problem with the previous stable verision. When I upgraded, I only upgrade KDE stuff, so it seems to be a KDE problem.
Comment 41 Nathan Toone 2003-12-21 03:19:59 UTC
I agree - the problem with this was filtering through spamassassin.  I had this problem on various version of kmail since 3.1, on through the current CVS version.  Shutting off filtering through spamassassin (by pre-fetching and assassinating, as was mentioned above), I no longer have this problem.
Comment 42 A T Somers 2003-12-21 09:28:32 UTC
Subject: Re:  KMail freezes the UI when checking for new mail

That's a workaround, not a fix IMHO. I can accept that getting the mail takes 
longer if you filter through SA (especially if you use VR too), but not that 
the whole program freezes, not that I can't type a new email at the same 
time.

Andr
Comment 43 Robert Cole 2004-01-20 16:01:43 UTC
Ditto with SA 2.62 and up to and including kde 3.2.0 rc1
Comment 44 Don Sanders 2004-03-19 07:41:31 UTC
*** Bug 77957 has been marked as a duplicate of this bug. ***
Comment 45 Bart Verwilst 2004-04-14 02:53:26 UTC
Still present in KDE 3.2.1.. SA is still blocking kmail.
Comment 46 J. Preiss 2004-04-27 20:27:53 UTC
I don't know if this is the same problem, but kmail freezes completly when I say "look every minute for mail" and it needs more than a minute... then I have to kill it :-( 
(KDE 3.1.4)
Comment 47 Till Adam 2004-05-13 08:51:10 UTC
*** Bug 81458 has been marked as a duplicate of this bug. ***
Comment 48 Stephan Kulow 2004-05-15 11:05:14 UTC
*** Bug 37054 has been marked as a duplicate of this bug. ***
Comment 49 Michael Jahn 2004-07-07 13:34:53 UTC
Just for the record: If this is closed bug #10549 can also be closed. Or, as they are very similar, just mark one of them as a duplicate. If this is decided upon bug #10549 should be marked as the duplicate to not lose all the votes ;-)
Comment 50 Robert Cole 2004-07-07 15:29:59 UTC
Still happens in KDE 3.2.3 and SA 2.63
Comment 51 Martin Spasov 2004-07-20 00:17:51 UTC
Kmail freezes when mail is piped trough external application (filters). The process is not backgrounded, it's blocking the entire Kmail (It's pita if you are spamassassin-ing and clamav-ing via pipes).
Comment 52 Robert Cole 2004-07-20 00:41:30 UTC
This must be one tough nut to crack having this bug exist this long and with 2060 votes. I'm sure someone will work their programming magic on this soon. :)
Comment 53 Dennis Jansen 2004-07-24 13:57:27 UTC
Yes, someone please thread these functions!
Comment 54 Paul Pacheco 2004-08-20 16:20:53 UTC
I thought this was on the feature list of 3.3, but it is still there. 

I will give $10 through paypal to whoever fixes this problem. I know it is not much, but I hope others will join me. 

A little more than just my 2 cents :)
Comment 55 A T Somers 2004-08-20 16:37:24 UTC
On Friday 20 August 2004 16:20, Paul Pacheco wrote:
> I will give $10 through paypal to whoever fixes this problem. I know it is
> not much, but I hope others will join me.
>
> A little more than just my 2 cents :)

Check out http://kontact.kde.org/shopping/sanders.php if you're willing to 
pledge some money. I did some time ago, but I'm not sure it actually 
helped :S

André

Comment 56 S. Burmeister 2004-08-25 22:36:03 UTC
Hi,

as it seems this matter is big and complex and thus not easy to solve so why not start little?

Some people, including me, complained about spam-filtering blocking kmail. As I regard spam-filtering as an important tool and it not being very complex in terms of filter-functionality, i.e. just piping and moving mail from a to b, one could start with a completely new filtering-engine from scratch.

Leaving the old filter-engine alone for the moment one could use the new one to filter spam, i.e. hardcode those rules, as a lot of users would not change them anyway. The other filters in kmail would not be influenced by this. Then slowly  one could extend the features of the new filtering-engine and step by step move more and more filters from the old one to the new one.

This way a major feature is targeted first and the work can be done without having to worry about the complexity of the old engine, little by little.

Although this might not be completely thought through, I think that it is not too far fetched to build a new house next to the old and move the rooms one by one.

Any comments?
Comment 57 Dennis Jansen 2004-08-26 01:05:01 UTC
Yep, good idea. If you like I can post the commands for DSPAM, would love them to be integrated, it's a nice free spam filter. (http://nuclearelephant.com/projects/dspam/)
Comment 58 Steffen Weber 2004-08-26 06:56:39 UTC
Would not it even be possible to integrate DSpam into KMail at source code level? I´m thinking about linking against the DSpam library or how it is called. I do not have that much programming experience (hardly any C++), but this should be faster than running an external application?!
Comment 59 Dennis Jansen 2004-08-26 15:46:08 UTC
Yeah that is possible. But it would mean KMail had either to be compiled statically with DSPAM or the DSPAM libraries at least have to be available for it to work, which shouldn't be the problem. But we'd need someone to program it.
Weird that after so much attention this feature this isn't implemented...
Don't other people get SPAM ? ;)
Comment 60 Andrea Landaker 2004-08-26 17:42:32 UTC
Integrating a spam filter in KMail might be a good idea; however, it's a separate issue, so it might be good to create a new wishlist bug for that issue (and link to it here, if you want).  This bug, while mostly seen when running external spam processes, is actually more general since it would occur running *any* long-running external process as a filter.
Comment 61 Stephan Binner 2004-09-25 00:52:25 UTC
*** Bug 90043 has been marked as a duplicate of this bug. ***
Comment 62 Till Adam 2004-10-03 23:21:49 UTC
*** Bug 89166 has been marked as a duplicate of this bug. ***
Comment 63 Tom Albers 2004-10-17 18:58:14 UTC
*** Bug 91286 has been marked as a duplicate of this bug. ***
Comment 64 jeff pitman 2004-11-05 09:57:42 UTC
I highly suggest rephrasing the title again to: "KMail freezes on blocking operations".  Seriously, the infra of Kmail may need a rethink on how to handle blocking operations: IO and network.

1. I have a external USB with a 200MB email file that kmail needs to reindex upon startup and it takes *forever* to even get any feedback about the operation.

2. LDAP operations freeze the UI: Bug#90211.

3. Failures in Kopete to connect addresses that have IM nicks will freeze the UI.  In other words, if Kopete cannot say whether someone is offline or not, Kmail will hang.

It would be really nice if some concept of "trust" were implemented into Kmail, it would make the UI more responsive.  Do we trust data from LDAP or Kopete to come back in a timely manner?

And it would be nice if blocking (IO, network) operations were handled such that a feedback mechanism could be appropriately implemented.

To sum up:

1. Handle blocking ops (threads or select/poll on fd, whatever).
2. Provide sufficient and consistent feedback. (the toolbar progress bar is nice)
3. Timeouts! And make them snappy. Like 5 sec.

And for crying out loud, why are there LDAP lookups when I'm just viewing the messages!

Anyway, this is just one of the growing pains of an architecture moving towards a more integrated approach with multiple apps communicating with each other.  Apps outside of DCOP make it all the more complicated.

Comment 65 Don Sanders 2004-12-27 09:32:18 UTC
Hi,

Here is a status report concerning the work we are doing, on making the 
filters work with imap folders so that mail may be filtered into imap folders 
59685. So that new mail in imap folders is automatically filtered 50997, and 
in making filtering mails into external tools like spam assassin 
non-blocking, a.k.a, asynchronous 41514.

Firstly I want to say that I'll close 41514 once I'm satisfied that filtering 
mail into an external tool like spam assassin no longer blocks for lengthy 
periods. Could people who have some other blocking problem please open up a 
new bug rather than comment on 41514 as commenting on 41514 will result in 
their feedback being forgotten when 41514 is closed.

What has been achieved in the last month? There is now a functioning prototype 
of KMail enhanced to support all the improvements listed above working in my 
laboratory at home where I work on a machine disconnected from the internet. 
I have also started using this system on my production machine at work. 
However I'm encountering problems just as fast as I can fix them so I 
anticipate it will take some time before things stabilize enough to commit 
the code to cvs. I apologize for this delay.

There is also a complication in that only mail manually filtered with 'Apply 
Filters', and incoming IMAP mails are currently being filtered using the new 
filtering system. Local, POP, and Sent mails (and disconnected) are still 
being filtered with the old filtering system. This means that mails filtered 
from these kinds of accounts can't be filtered/moved into imap folders (even 
though that appears as an option in the filter dialog).

I've promised not to address Local, POP, and Sent mails, before completing a 
'Quick insertion of common phrases' feature. Thus it seems necessary for me 
to now work on asynchronous filtering, imap folder targets, automatic 
incoming imap mail filtering, and quick insertion of common phrases 
simultaneously. Which is what I plan to do in the following weeks.


If people are interested in the details of the currently known bugs they are:

POP, Local, Sent (and disconnected?) accounts need to be ported over to using 
the action scheduler.

Need to automatically check imap inboxes when new mail is discovered in them. 
Currently need to manually kick of filtering by changing into an imap inbox.

I don't have any logic for handling crashes. Mail shouldn't be lost but in the 
event of a crash some mail may not be filtered.

Somewhere in the networking stack below KMail (KIO or the IMAP server I'm 
using in my lab) there is a problem that is causing a lot of timeouts and this 
means some mails are not being filtered.

I'm only about half way through my tests, I'm currently still in the stage of 
encountering new problems just as fast as I fix the old ones.


Finally I'd like to say thank you again to all the people who are funding the 
development of these features for all KMail users, through the commercial 
improvement system. We really appreciate your support.

Don Sanders
http://kontact.org/shopping/sanders.php

Comment 66 Andreas Gungl 2005-01-18 20:22:54 UTC
*** Bug 96500 has been marked as a duplicate of this bug. ***
Comment 67 Peter Ruskin 2005-01-18 21:58:53 UTC
It's still there, perhaps worse, with kmail-1.7.2, and I've just installed KDE-3.3.91 (beta1) (kmail-1.7.91) and that is the same too.
Comment 68 Unknown 2005-01-18 22:30:09 UTC
When receiving Mail, filtering also interrupts the message download, very annoying if you have to pay your connection per minute.

(I think this belongs to this bug, because it is the same problem, both receiving mail and filtering should be non-blocking operation not only to the UI but also to eachother. If not please tell me and I will open a new one)
Comment 69 Andreas Gungl 2005-02-05 21:34:11 UTC
*** Bug 98336 has been marked as a duplicate of this bug. ***
Comment 70 Don Sanders 2005-03-16 08:08:48 UTC
Add kmail-devel as per Ingo's request. (Hopefully I understood correctly).
Comment 71 Bavo De Ridder 2005-04-06 22:10:29 UTC
I have the same issue. I have 20 filters or so defined, the first one to be spamassassin filtering. Every time I have email, kmail freezes until all the email is processed. It freezes from the first email (0% progress bar) up to the finish (100% progress bar), with the occasional redraw.

This happens on KDE 3.4, SuSE 9.3. 

It shouldn't be that hard to implement a threading mechanism like "worker - boss" as mentioned above.
Comment 72 esigra 2005-04-07 05:56:57 UTC
I also have the same issue. But it was certain messages that KMail froze on, usually large (175 kb) but sometimes also smaller. Sometimes it was frozen for several minutes, so I had to kill it, log into webmail and delete the messages that i think froze it, log out, restart KMail, see if it can could handle the remaining messages, repeat ....
It was quite a work to get the mail under those conditions. Now I have switched over to thunderbird, which I do not like as much, but I had no choice. I even tried turning off the spam checking filters, but the problem remained. I use kde 3.3.2. Before that version I have used KMail for several years.
Comment 73 Anders E. Andersen 2005-04-07 08:41:23 UTC
Re: #72

That's not what this bug is about. The 3.3.2 version you used must have not liked your system, or your system must have had something else wrong with it. This bug has been around at least since Kde3.0.0, so if you have used any version of those without problems, then that is a definite sign that you have experienced a problem that is unique.
Comment 74 Unknown 2005-05-21 15:26:43 UTC
This bug is getting more and more annoying if you use kontact with all it's components, because even news reading or organizing something in your agenda will be blocked during filtering. Even if you disable spamassassin, the mail checking and filtering freezes the GUI. So just making spamfiltering an unblocking operation does not solve the problem.
Comment 75 Pascal Cavy 2005-05-23 11:52:06 UTC
during filtering my 1.7 P4 cpu is at 100%, investigating kontact performance issues as well as renicing filtering subprograms might help too.
Comment 76 Matthias Wieser 2005-06-13 01:16:52 UTC
Created attachment 11420 [details]
Filter to show lock in pipe

add this filter in front of all other Filters with the following setting:
Match: Message Contains: .
Do not stop filter after that filter.
The python script does nothing accept sitting there for 10 seconds and after
that forward input to output (example off a really slow filter like
spamassassin, but showing the lock does not occur because of the work, but of
the bad implementation of the pipe - filter)
Comment 77 Matthias Wieser 2005-06-13 01:22:39 UTC
Created attachment 11421 [details]
Idea to solve that lock - ask for feedback 

This patch just makes the Process not blocking, 
adds a kapp->processEvent().
Is that what do a yield on other implementations?

Thanks for looking at the patch :-)
Matthias
Comment 78 Don Sanders 2005-07-19 02:12:11 UTC
I've posted an update to Bug#50997 ( http://bugs.kde.org/show_bug.cgi?id=50997 ) that is relevant to this bug also.

I have attached a patch to that report which implements more asynchronous filtering (it's not possible to make any code truly totally async) for manual filtering and are currently working on making filtering (relatively) async for incoming mail for online imap accounts.

I intend to port other account types and usage of filters to the new filtering engine also, (as time permits).

Don Sanders http://donsanders.org
Comment 79 Don Sanders 2005-08-22 13:43:14 UTC
I've now submitted patches to add online IMAP filtering to KMail. This has been done using the new less blocking filtering system. Especially in conjunction with Till Adam's work this should make spam filtering less blocking.

This work should be included in the KDE 3.5 release. But the less blocking filtering will only be available for online IMAP filtering (and in special cases manual filtering).

It should only be a small amount of coding now to get less blocking filtering for pop and local accounts (and sending) but it requires substantial testing. So the potential is there to get this done by 3.5 but it needs more work than I alone can currently deliver.
Comment 80 jsweatte 2005-10-14 19:29:29 UTC
Benjamin, did you mean to send anything else/ As you can see thare wasn't much 
in the note I got from you?
Joel Sweatte

On Monday 10 October 2005 17:49, Benjamin Martin wrote:
[bugs.kde.org quoted mail]
Comment 81 A T Somers 2005-12-07 11:40:06 UTC
Problem is still there for POP in KDE 3.5
Comment 82 Vincent Panel 2005-12-07 15:44:46 UTC
#81 : Have you read comment #79 ?
Comment 83 David Faure 2005-12-12 13:41:26 UTC
Note that I have just fixed a bug in IMAP mail-checking which would freeze the UI after checking each folder (proportionally to the amount of mails in the folder), and especially more so on NFS. So this falls into the description of this bug, but of course there are other unrelated reasons for GUI-freeze mentionned in this report... I just want to encourage everyone with imap-related (and not filter-related) UI-freezing to update to the latest SVN or 3.5.1 when it's out.
Comment 84 Ismail Donmez 2005-12-13 18:35:21 UTC
David,

I tested your patch but while it really improves the case KMail still tries to process old mail on online IMAP account, I can see this easily because it tries to filter old mail again and again. But surely the case is improved.
Comment 85 Ernest ter Kuile 2006-02-04 20:33:02 UTC
This bug is most annoying when _writing_ mail. 

What about Starting a separate process handling the separate window where the user is writing his email. I cannot believe this has to be handled by kmail directly. 

Note: currently running kde 3.5, with 2 pop3 accounts and filtering via spamc.
Bug is still there, and worse than ever.
Comment 86 F Reifenstahl 2006-02-06 09:26:34 UTC
Concerning #85 I quite agree. It peeves me quite often.
Comment 87 Ferenczi Viktor 2006-02-07 02:38:19 UTC
Use ClamAV and SpamAssassin with KMail. This will increase the delays to many seconds per mail. KMail is unusable when it checks for new mail and got something to filter.
Comment 88 Shai 2006-02-07 09:06:58 UTC
I've been using KMail with spambayes as a filter for quite some time now, and I must say, unlike commenters #85, #86 and #87, I have seen a huge improvement in KDE 3.5 and especially 3.5.1 (KMail 1.9.1), in this issue and other performance issues.
Comment 89 Dominik Karall 2006-02-07 12:11:32 UTC
As Ferenczi Viktor says (#87), try to use clamav and spamassissn and you will see that there is no improvement since KDE 3.4.x.
Maybe your spambayes filter or KDE is running faster, but I don't think that the bug was handled in any way.
Comment 90 A T Somers 2006-02-07 12:32:25 UTC
Maybe it would be relevant to mention the type of account you use. I have not
seen any improvement in KDE 3.5.1, using POP3 accounts with Spamassassin.
Fetching and filtering still blocks all of Kontact for a considerable time. I
really think that mail fetching and filtering belong in a separate thread, but
I guess that is a pretty complex change to make.
Comment 91 Unknown 2006-02-07 12:58:03 UTC
even if it is working faster with spambayes might be faster now, this is only due to performance enhancements in spambayes. Still it is not solving the main problem: the blocking behavior in everything kmail does. I use kmail on a slow (933MhZ Crusoe) laptop and have quite many filters set, even this interrupts kmail for a second from time to time. spamassassin uses up to 25 secs per mail! This is just not usable! It is more than annoying writing an email and see the whole sentence you wrote after half a minute. By counting the number of spam mails I get (these are not all mails that are filtered) this already sums up to 1hour daily!
It may sound arrogant, but when I started programming I was told to split UI and intensive operations in different threads (and give the UI interface the higher priority). Because the UI does not need much cpu time, but if it is needed, it is needed directly for the user _not_ to experience any delays.

BTW, if used with Kontact, Kmail freezes everything, making all Kontact apps unusable for this time.
Comment 92 Roger Larsson 2006-02-07 17:52:32 UTC
I use fetchmail so for me kmail only works on local mailboxes.
But this will still block the UI.
In my pipeline of things to do is to move my spamassassin scan
to normal mail processing (i.e. out of kmail) [to .forward ?]

Could this be an option? To do it the Unix way?
Let kmail configure fetchmail, local mail... wait for arrival of scanned
messages - do only the filtering in kmail.

But what about IMAP?
Comment 93 Don Sanders 2006-02-08 01:03:11 UTC
Regarding IMAP, yes there is now non-blocking IMAP filtering. I still 
have POP and Local accounts to go. These should only take a few days 
each to get a prototype patch working, but I'm very busy.

Regarding blocking operations in general that's a complicated topic I 
think too complicated to discuss here.

Please see comment #65 for more info. That comment is still current.
Comment 94 Marijn Schouten 2006-02-15 16:02:13 UTC
I just configured KMail today to use my university IMAP server. I've not changed any filtering options and from looking at them no filtering is being done. I've some 4500 mails in my inbox. KMail has been busy for at least an hour so far and all it has to show is the number of mails and the number of unread ones. The main window says:

Retrieving Folder Contents
Please wait . . .

the sidebar and menubar are responsive, although nothing useful will show in the main window.

I'm using KMail 1.9.1 from Gentoo
Comment 95 Marijn Schouten 2006-02-15 16:05:11 UTC
Oh, and my CPU load is just a few percent
Comment 96 Marijn Schouten 2006-02-15 17:37:55 UTC
after I killed KMail and started it from konsole, KMail is usually responsive, although it doesn't actually finish loading any of my folders.
Comment 97 S. Burmeister 2006-02-15 18:34:26 UTC
If I understand you correctly, your issue is about generating the index for an IMAP-folder. While it is true that kmail is awfully slow at that compared to thunderbird, which indexes a thousands of messages in a few seconds without freezing anything, IMO that is a different bug, as this bug is about filtering.

So if I am right, you should report a seperate bug which states that kmail is slow on indexing IMAP-folders.
Comment 98 Sebastian Turzański 2006-02-22 10:57:04 UTC
this problem started to apear when i starated to use pipe through spamc
Comment 99 Martin Steigerwald 2006-02-26 14:44:37 UTC
Hello,

I filter my mail through bogofilter and during bogofiltering incoming mail KMail's GUI is not very responsive. It often stops window refresh for several seconds on my IBM ThinkPad T23 Pentium 3 with 1.13 GHz. I know bogofilter with a 40MB+ words database is expensive, but the GUI shouldn't lock up, especially while I am trying to type in a new mail. bogofilter should be called in the background.

As there is a second problem reported in this bug report which goes about sorting maybe it would be a good idea to make two bug reports out of this one?

It will be some time till KDE4 and I really would like to see asynchronous filtering for some KDE 3.5.x release - as many other users I guess. I am willing to spend time into testing non-blocking filtering for POP, IMAP and local mail (see comment #79). Where to start? I guess I would need to compile my own KMail with some patch?

Regards,
Martin
 
Comment 100 Ismail Onur Filiz 2006-03-17 02:19:43 UTC
*** Bug 123763 has been marked as a duplicate of this bug. ***
Comment 101 Daniel O'Connor 2006-03-17 02:48:01 UTC
I am not sure 123763 IS a duplicate - I get hitching in network activity, not hangs.

Also, I don't have any filters running, and the problem happens on every folder, not just ones with email.
Comment 102 Pieter 2006-04-11 10:03:19 UTC
Probably related:
-very long stalls (>45s) when I move a message to a different folder
-very long stalls (>45s) when I send a message (SMTP)

KMail 1.9.1, in Kontact 1.2 (Gentoo)
Comment 103 A T Somers 2006-04-11 12:31:59 UTC
Quoting Pieter <pieterg@hotpop.com>:

> Probably related:
> -very long stalls (>45s) when I move a message to a different folder
> -very long stalls (>45s) when I send a message (SMTP)
>
> KMail 1.9.1, in Kontact 1.2 (Gentoo)


I don't think this is (directly) related. This bug is about long stalls due to
slow connections and/or filtering processes. The last issue (SMTP) is 
something
similar, but not identical.

Andre
Comment 104 Shai 2006-04-11 13:13:16 UTC
A T Somers wrote:

> Quoting Pieter <pieterg hotpop com>:
>   
>> Probably related:
>> -very long stalls (>45s) when I move a message to a different folder
>> -very long stalls (>45s) when I send a message (SMTP)
>>
>> KMail 1.9.1, in Kontact 1.2 (Gentoo)
>>     
> I don't think this is (directly) related. This bug is about long stalls due to
> slow connections and/or filtering processes. The last issue (SMTP) is 
> something
> similar, but not identical.
>
> Andre
>
>   

True, but the underlying issue (KMail's single-threadedness) is the same.
Comment 105 Roger Larsson 2006-04-13 10:21:23 UTC
This is probably unrelated...

I reconfigured my email system to use fetchmail to get the files.
procmail and spamassessin to filter.
And then let kmail read from local prefiltered folder only.
This has worked well but today I run into a major slowness...
My Trash folder had grown, uncontrolled, to over 40000 messages.

Kmail started to crawl... worse than ever...
Comment 106 Roger Larsson 2006-04-13 10:33:35 UTC
It was not the Trash folder... problem back again...
Noticed that i have Search folders... I suspect them instead.
Comment 107 Pieter 2006-04-25 01:36:54 UTC
yes, you're right about that.
I had about 25 search folders, created over the last few months.
During those months, kmail has slowed down gradually almost to a complete stop.
Removed all search folders (took me >20 minutes, waiting for response after every single mouseclick...)

And now that they're gone, the speed is back to what it was a few months ago.

I noticed that all search folders contained the same contents: all new messages, and all messages I had selected during the day.
The original search queries were gone, so it seems not to make any sense to keep the search folders for so long.
Comment 108 Ian Ventura-Whiting 2006-04-27 21:14:03 UTC
Threading is definately the solution. However, threading support is much better in QT4 than in QT3. I have recently ported a thread-based application to QT4 and it would be easier to implement it then, rather than waste time developing it now and redeveloping it latter. This problem has been in KMail for quite a while and and maybe we should just wait until KDE 4 is out.
Comment 109 Frederik Schwarzer 2006-04-28 23:54:29 UTC
My version (1.9.1/KDE 3.5.2/Debian Sid package) is slowing down (or freezing) too for a few seconds if anything changes in one of my mailbox (inbox, trash, ...).
This problem exists for me since I startet using kmail.
It appears on:
1. new incoming mail with a high speed connection, not a 56k modem
2. selecting a new mail (marking it as "read")
3. moving mail to another folder (trash as well).
So on every action in mailbox the UI freezes for a few seconds.

Since I installed spamassassin kmail furthermore seems to crash from time to time on one of those actions. I retraced it on moving mail to trash. The CPU usage grows to 100% and the UI doesn't respond. After one or two minutes I killed the prozess.
Every time this happened, I used to move several mails to trash in a row so it might be a problem with too many changes in mailbox in a too short time.

regards
Comment 110 F Reifenstahl 2006-08-07 11:32:46 UTC
Last week we have had an email server breakdown. After two days kmail had to process some thousand emails... I appreciate that this might take a long time, but it lasted very, very long... and the most annoying thing was that I wasn't able to edit and send any email during a couple of hours! AISI in daily use in business this is a k.o. for kmail as a business application.

My suggestions: Fetching and filtering of newly received mails should be a two step process, where fetched mails should be stored in a temporary but accessible folder and moved to their actual destination in a second step. And much more important, receiving and editing/sending of mails shold be decoupled unconditionally.
Comment 111 Ingo Klöcker 2006-08-07 12:00:19 UTC
Just to keep you up-to-date: The solution for this problem will be the new storage backend Akonadi that we'll introduce with KDE 4.

As for the last comment: In business all mail should be checked for being spam or containing virusses on the mail server. Since it's spamassassin which is causing most of the pain checking mail already on the server would make using spamassassin via KMail unnecessary and thus considerably ease the pain this bug is causing you.
Comment 112 Maciej Pilichowski 2006-08-07 12:45:37 UTC
> Since it's spamassassin which is causing most of the pain

Same with bogofilter. KMail simply doesn't handle gently filtering, it is not spamassassin problem.
Comment 113 Ingo Klöcker 2006-08-08 10:43:18 UTC
Sure, but bogofilter is said to be magnitudes faster than spamassassin, so with bogofilter this problem should be much less annoying.
Comment 114 Unknown 2006-08-08 12:59:27 UTC
Anyhow, the problem is not the program used for filtering, you have significant slow downs if you just have a lot of filtering rules (e.g. I have something >100). The real problem is that kmail is blocking the GUI for each and every action it makes. You can't continue writing mail during receiving, filtering or sending mails, etc.

I just entered yet another blocking: If Kmail is waiting for a Kwallet to open, you are not able to open a Konqueror window showing your home directory (in fact, if you try to open it several times, nothing happens and if you open the wallet, you'll get all the missing windows.)

So again: The problem is in fact not the filtering at all, GUI should always be implemented non-blocking from any (backround) processes.
Comment 115 Anders E. Andersen 2006-08-08 13:04:51 UTC
WE KNOW!!!!!!!

Sigh...
Comment 116 Michael Eichst 2006-08-09 17:58:36 UTC
Am Dienstag, 8. August 2006 10:44 schrieb Ingo Klأ�cker:
> ------- Additional Comments From kloecker kde org  2006-08-08 10:43 -------
> Sure, but bogofilter is said to be magnitudes faster than spamassassin, so
> with bogofilter this problem should be much less annoying.

I just cleared my spamfolder to wastebasket. It takes 15 seconds with 815 
spammails there. Too much time not to feel disturbed in your workflow.
If You don´t bother about economic working forget about professional users. 
They will simply use another mailklient.
greetings
Michael Eichstädt
Comment 117 Vincent Panel 2006-08-09 18:34:36 UTC
Wow 3888 votes and still counting :) Note that with Akonadi, the problem is still there : separation between the frontend and the backend. Does fixing this bug requires a complete kmail rewrite ?
Comment 118 Don Sanders 2006-08-10 04:59:34 UTC
I believe this problem has been addressed for IMAP, what's left to do is solve the problem for POP.

> Does fixing this bug requires a complete kmail rewrite ?

No, it requires someone spending a few days to reuse the IMAP solution for POP (assuming the IMAP solution is working ok and as best I can tell that is the case). If someone wants to do this give me an email and I'll explain how.

Personally I don't see how rewriting the backend with Akondai will help fix the issue either.

Sorry guys, but I have other priorities in my life now. This is meant to be open source so other people can contribute.
 
Comment 119 Maciej Pilichowski 2006-09-28 09:08:35 UTC
I am not talking here about fully operational multi-threaded processing but just refreshing the windows -- so the window won't be blank all of the sudden. I don't know how about Qt, but in Delphi it would like this: 
  while (am_I_still_processing_data()) 
  { 
    process_data(); 
    Application.ProcessMessages; // it ensures events are sent and window is refreshed 
  }

Currently when I switch to other app and back KMail looks like dead, white rectangle, pretty ugly -- it would remedy only this, not problems noted in #0. Anyway worth a try.
Comment 120 A T Somers 2006-09-28 10:04:48 UTC
Quoting Maciej Pilichowski <bluedzins@wp.pl>:

> I am not talking here about fully operational multi-threaded
> processing but just refreshing the windows -- so the window won't be
> blank all of the sudden. I don't know how about Qt, but in Delphi it
> would like this:
>  while (am_I_still_processing_data())
>  {
>    process_data();
>    Application.ProcessMessages; // it ensures events are sent and
> window is refreshed
>  }
>
> Currently when I switch to other app and back KMail looks like dead,
> white rectangle, pretty ugly -- it would remedy only this, not
> problems noted in #0. Anyway worth a try.
>

Such a thing is far from trivial in a complex real world application, because
such a message (like the clicking of a button by the user) could trigger a
chain of actions that interfere with the currently running process in complex
ways. ProcessMessages() (yes, it exists in Qt as well) is by no means a magic
bullet here.

I still think that the main mail processing should be in one or more separate
worker thread(s) from the UI. Maybe that will become more easy after KDE4?

Andr
Comment 121 Emil Kirschner 2006-10-27 11:58:21 UTC
blocking also happens when moving messges from one folder to the other or when importing messages (from thunderbird, for example).
Comment 122 Albert Astals Cid 2006-10-28 16:25:58 UTC
*** Bug 122164 has been marked as a duplicate of this bug. ***
Comment 123 Predrag Viceic 2006-10-31 11:41:02 UTC
This freeze has become even worse with spamassassin enabled (NOT via spamd).
Comment 124 Ferenczi Viktor 2006-10-31 16:12:58 UTC
I've solved this by using our own mail server with spamassassin and friends, but it's not an option for the ordinary user having only a POP3 account without any server side SPAM filtering...

This bug is more, than 4 years old and still unsolved.

It'll go to elementary school very soon. ;-)
Comment 125 Alex Fiennes 2006-10-31 16:22:06 UTC
One can always pick up the mail with an external process like fetchmail, use procmail to run it through spamassassin and then grab it with kmail once it has been analysed, but it would be nicer if the bug was fixed.
Comment 126 Tommi Tervo 2006-11-01 12:19:00 UTC
*** Bug 136615 has been marked as a duplicate of this bug. ***
Comment 127 Ulf Bartholomäus 2006-11-02 22:44:07 UTC
Hallo, ufff, ready to read this tread :-)

My Kmail Version 1.9.5 from KDE 3.5.5 (OpenSUSE 10.1 - updated).

But I have two problems what I think are not the same as above.

First, sometimes after I start Kontact / Kmail and I type my password in the Kwalletmanager Window and quit it with OK, the kded task goes to 100% (Athlon 64 3200+ over more than 1 hour). Only if I kill the kded and restart it manually it works. (I don't know if it is a part of this problem - otherwile I post it in a new thread).

Second problem is a hanging input if I write mails. It is very angrily, if I write a email and no types are viewing in the editor window. Normally it should no problem to make the editor in a extra process or task. How it works with a external editor?

Ulf
Comment 128 Bram Schoenmakers 2006-11-18 23:57:43 UTC
*** Bug 137546 has been marked as a duplicate of this bug. ***
Comment 129 Olivier Magere 2006-11-23 18:10:18 UTC
Freeze make kmail difficult to use on a machine that's not running all day long.....
Comment 130 Raga Prong 2006-12-31 15:29:41 UTC
I can confirm this bug with v 1.9.5. It takes 10 seconds until the window is refreshed - till then, you can draw on the frame by moving dialogs. Don't know if it is the filtering or the indexing that slows down kmail, but threading seems to need improvement here.

Happy new year
Raga
Comment 131 Ulf Bartholomäus 2007-01-08 10:50:05 UTC
For me is the blocking from text input from the Email Editor the main problem. If you have many email accounts, with many email's per day, it is very problematic to write a email. You put the text in the editor and don't look at the screen. If you look at the screen after a time, you see that nothing from your last input is available ... Panic .... :-( . But after a while (30 to 300 seconds) the keyboard buffer was written in the edit field. This is a very big problem for me. 

What is a Work around for this? What is the problem that the Editor is not a separate process?

I think a solving of this problem is not in the stack :-( (see comments above).

Happy new year
Ulf
Comment 132 Jake Martin 2007-02-13 23:05:43 UTC
I don't see the point of even having a message download progress bar when you can't even see it because the entire UI is locked up when downloading messages.

Sending and receiving operations really need to be threaded.
Comment 133 F Reifenstahl 2007-02-15 11:25:01 UTC
I don't know if riddance from that feature will still be a long time coming, but as an intermediate workaround I would appreciate an option "suspend fetching while editing". It would save at least half of the wasted time and nerves.
Comment 134 Bram Schoenmakers 2007-02-18 11:22:27 UTC
*** Bug 141852 has been marked as a duplicate of this bug. ***
Comment 135 F Reifenstahl 2007-03-06 17:11:06 UTC
Today is the day... I'm leaving       :`(

kmail being asleep for five days (me myself I had been sick during that time), I started it this morning to get all what has been waiting for me, and kmail chomps... and chomps... and chomps... something, I had to bear several times during the last years. People called me asking why I didn't call them, they had requested in their emails...*chomp* ... I couldn't read or write any email. Well, I killed that process and began to migrate, and now I'm a Thunderbird user.

I don't write that with any malicious glee, after working with kmail for I-don't-know-how-much-years it's a lttle bit sad to be forced to resign. But I can't take responsibility for using a tool at business that balks my work in a way kmail does. kmail is an excellent tool with many UI features I'm already missing by now. And I know, it's OpenSource, so nobody is entitled to arrogate for this or that. But to catch especially the fancy of those who coordinate developing of KDE apps, I have a hunch that developing of such important tools 
should be more oriented to business workflow.

So, no offence, I'm sure kmail will get rid of that problem, anytime. Maybe I'll switch back...

Have a good time, regards
Comment 136 Predrag Viceic 2007-03-07 08:28:52 UTC
I agree with the post #135 even though I don't have the courage to migrate my 7 years worth of mail to an another client..
Comment 137 F Reifenstahl 2007-03-07 13:23:48 UTC
Hi Predrag,

I don't wanna be suggestive to incite you to switch, but me myself I had about 30 mail pots filled with about 20,000 messages. Migration took about an hour and was a straightforward operation.
Comment 138 Ferenczi Viktor 2007-03-07 14:28:00 UTC
This bug slowly becomes a "How to migrate from KMail to X" forum.
I don't want to migrate for now, since my configuration is not affected
by these slowdowns any more. I had to relocate SPAM and virus filtering
to our mail server to achieve this. Sadly, this is not an option for many-many 
users. I hope there will be a much reliable version of KMail in KDE4.

Greetings, Viktor
Comment 139 Martin Steigerwald 2007-03-07 14:46:59 UTC
This is a bug tracker for KDE... its anyones own decision to migrate to another mail client or not, but this IMO is definately not the right place to discuss migration issues. Remember that any post to this bug report is sent to a lot of people subscribed to the bug in order to get news regarding its status! I for example am not interested in reading a discussion about migration issues.

So please stay on topic and discuss migration issues somewhere else. Thanks.
Comment 140 Sebastian Turzański 2007-03-07 19:04:06 UTC
so back to the point - this bug's status is "ASSIGNED" so just to have it clarified comes my question - 

Is somebody trying to make it fixed in kde3 or is all the work beeing done only for kde4?
Comment 141 Predrag Viceic 2007-03-07 19:09:04 UTC
I wouldn't hold my breath..it's assigned for five years now..In the meantime I have replaced Spamassasin with CRM114 and things got better...
Comment 142 Martin Steigerwald 2007-03-07 20:45:55 UTC
Well for spamfiltering this is a work around for the current KMail limitations: 

See https://bugs.kde.org/show_bug.cgi?id=136261

English article, available online:
http://www.linux-magazine.com/issue/77

German article, not yet online (should be after a year):
http://www.linux-user.de/ausgabe/2007/02/

Please don't discuss questions about it here. If you want to help with improving CRM114 in KMail support, contact me and if you have suggestions add them to the bug report mentioned above instead. Thanks.
Comment 143 Anders E. Andersen 2007-03-07 20:58:39 UTC
I don't think anybody is working on it at the moment. The guy that was investigating it seems to have given up due to the problem being too complicated and having too little time to fix it.

For me this bug really isn't an issue anymore. I run my own mailserver and the mail is filtered through spamassassin via procmail on the server, so the mail all winds up in the right folders without kmails involvement, and I use IMAP, not POP3 (otherwise serverside filtering wouldn't make any sence either).

From what I can gather, the non-threadyness of the mail fetching loop is so deeply intertwined with the rest of kmail, that adding threading would be unrealistic.

In other words.. KMail needs to be rewritten from scratch with threading as a central design principle. Anybody up for this? :)

Alternatively you can try Mailody, which is the new new alternative mail application for KDE. However they seem to have their own ideals on how an email app should work, and perhaps others might not agree with those ideas. And is it still IMAP only?

Then there are non-kde clients...

I would personally vote for a rewrite. And before you start pointing fingers, I don't know the first thing about C++ or QT programming, and last time I tried KDevelop (which is not that long ago actually) it was, ehrmm, not easy to figure out compared to the IDE I am used to. Excuses excuses.
Comment 144 Bram Schoenmakers 2007-03-08 23:03:03 UTC
*** Bug 121207 has been marked as a duplicate of this bug. ***
Comment 145 Peter Ruskin 2007-03-09 16:51:56 UTC
Thanks to Comment #142, I have also switched from spamassassin to CRM114 and there is a marked improvement.
Comment 146 Peter Ruskin 2007-03-11 23:19:05 UTC
Re: Comment #145 - ...except that CRM114 doesn't work well enough for me so I've gone back to using spamassassin.
Comment 147 Thomas McGuire 2007-04-11 21:41:36 UTC
*** Bug 144091 has been marked as a duplicate of this bug. ***
Comment 148 Störm Poorun 2007-04-29 18:51:03 UTC
I am suffering this bug (which has been assigned for 5 years!).  I am running openSuse 10.2 with kmail, I have several folders containing between 5-20,000 emails (!), but I was suffering from this bug even before I had such full folders. In addition to the kmail gui freezing, my kicker panel and kickoff menu freeze and sometimes crash whilst kmail is downloading email. This bug is really dysfunctional and is a real blocker.
Comment 149 Adam Porter 2007-04-30 04:50:25 UTC
I'm just another user, but I'm at a loss: I have never had a problem with KMail's UI freezing or blocking while checking new mail.  I can freely use KMail in any way while it's downloading mail.  I have one local mail account (/var/spool type), and two disconnected-IMAP accounts.  I have them set to automatically check every 20 minutes, and I also hit the button manually sometimes.  I've used KMail for a couple of years now, and I've never had any such problems.

I'm on Debian testing/unstable with KMail 1.9.5 from 4:3.5.5.dfsg.1-6.
Comment 150 Guillaume Pratte 2007-04-30 06:00:56 UTC
The problem comes from using an external application to filter spam, like bogofilter. KMail becomes unresponsive, even on modern hardware.
Comment 151 Kai Krakow 2007-04-30 12:52:47 UTC
I think KDE GUI parts (like kicker) but also applications (like kopete) block sometimes due to this bug because the KMail subsystem widely integrates with the KDE system (kopete using the adressbook, KMail using the kopete online status, kicker having kmail applets or systray applets running). When I start KMail after the weekend at work and it checks many mails and blocks due to running the spam filter, I cannot work with several parts of KDE: Kopete blocks, konqueror starts up very slowly or even after kmail has finished, Kopete blocks. Even Kopete startup makes kmail and parts of KDE blocking. I suppose this is all related. KMail should fork a thread for filter actions and manage a queue for running it.
Comment 152 Ulf Bartholomäus 2007-04-30 13:05:58 UTC
In Comment #150, Guillaume Pratte detects the right reason. The main problem is the use from external applications, so as spam filter, virus scanner and so on. I don't not know the reason, why the programmer not use a separate thread or process for this. No serialisation is need for this?!
Comment 153 Anders E. Andersen 2007-04-30 13:15:54 UTC
We all know what the problem is ladies and gentlemen. I think the major point here is:

Patches are welcome!

In other words.. Fix it yourself or stop complaining! Please! Don't mean to be rude, but I really think there is too much whining in these comments. The assignee has made it clear above that he doesn't have the time to fix this, so its up to you. This is open source, people. Contribute!
Comment 154 A T Somers 2007-04-30 16:23:36 UTC
Might I suggest that the status is changed to unassigned then?
Comment 155 Miguel Angel 2007-04-30 16:47:26 UTC
Re: Comment #153
So much for "Fix it yourself"; what happens to bug 97925?
The patch is there sitting since 2005, still awaiting.
Comment 156 Anders E. Andersen 2007-04-30 16:53:43 UTC
I would like to second Somers' suggestion. Status is should be unassigned.
Comment 157 Ingo Klöcker 2007-04-30 18:45:18 UTC
Reassigning back to kmail-devel.

FWIW, this problem will be fixed once we have switched to Akonadi. Unfortunately, due to our scarce man power this won't happen before KDE 4.1.
Comment 158 Störm Poorun 2007-04-30 20:05:58 UTC
I'm really pleased to hear that it will be fixed in Akonadi come KDE 4.1 (comments: <A HREF="#c111">#111</A>, <A HREF="#c157">#157</A>). However, it would be much appreciated if anyone were able to give a very brief explanation as to how this will deal with the bug - particularly considering comments by others, including <A HREF="#c117">Comment #117</A>, which averred to the need for a complete re-write.

I should clarify that my post <A HREF="#c148">Comment #148</A> was actually intended to cover news related issues (for example kicker and kickoff crashing/being unresponsive) by way of relevant reporting rather than a direct complaint. Such report was in my view quite reasonable, as these issues are apparently directly caused by this bug and had not seemingly been so far reported anywhere here. The fact that this bug was opened in 2002, and is generally considered KDE's No 1 bug, just compounds matters, thus it is not unreasonable to encourage a small degree of discussion.
Comment 159 Ingo Klöcker 2007-04-30 22:08:26 UTC
A complete rewrite is more or less what will happen because the whole backend (including filtering) will be provided by Akonadi. Since filtering will be done by Akonadi KMail (which will then basically be just a GUI for Akonadi) will stay responsive.

As for comment #148 I think this might be caused by the quick search in the Kicker menu which also lists email addresses AFAIK.
Comment 160 Thomas McGuire 2007-07-17 16:17:29 UTC
*** Bug 147928 has been marked as a duplicate of this bug. ***
Comment 161 David 2007-08-20 18:46:56 UTC
Same thing's with kopete when getting messages.
Comment 162 Stephan Sokolow 2007-10-06 12:30:19 UTC
I haven't used KMail since it wiped my address book and started telling the GMail server that it had downloaded mail without adding it to my local inbox, but the Kopete issue definitely annoys me.
Comment 163 Markus 2008-01-31 15:59:59 UTC
With qt4 supporting threads much better will this annoying bug eventualy be fixed in the ported kmail for kde4?
Because its really embarrassing that such a good application like kmail is having such a bad problem.
Fireing up a thread to check mails and put them in the tmp folder where another thread will read the tmp folder and filter them is imho not a task to take SIX YEARS to implement ;)
Comment 164 Anders E. Andersen 2008-01-31 19:45:25 UTC
Markus if you took a look at the comments just a page further up, you will see that KMail is being redone to use Akonadi. This wont be ready until KDE 4.1 though (maybe later?).
Comment 165 Markus 2008-02-02 16:19:37 UTC
Sorry for being unclear. Is Akonadi multithreaded?!

The problem I have is that while kmail is filtering it keeps the network connection until new mails can be filtered (at least thats what I think) and so the connection is timeing out when using an av and spamassassin with online-checks enabled. So mails arrive multiple times and other with a big delay.
When akonadi does it the same way, the problem persists. (as it fetchs and filters the mails)
I thought akonadi is much more than a "kmail backend" ;)
Comment 166 Thomas McGuire 2008-03-31 01:00:41 UTC
*** Bug 159610 has been marked as a duplicate of this bug. ***
Comment 167 Andrew Min 2008-07-22 23:38:07 UTC
Same here with Gmail's IMAP when getting "All Mail" (a huge folder, I've had it since 2005).
Comment 168 Caleb Cushing 2008-08-11 11:08:07 UTC
not sure if the new kmail is threaded but things don't seem to be locking up on me. I can say that I'm satisfied with 1.10.0 (kde 4.1.0) performance in this area. I would suggest all subscribers of this bug to look at it.
Comment 169 Anders E. Andersen 2008-08-11 11:43:08 UTC
Just to reiterate, for those who are too lazy to read a few pages up. The KMail backend is planed to be replaced by Akonadi for KDE 4.2 (last I heard). For now it still uses the same engine as 3.x, which means it still checks mail in the main thread.

Akonadi roadmap:

http://pim.kde.org/akonadi/roadmap.php
Comment 170 kdeuser1234 2008-11-01 14:21:46 UTC
akonadi is going to be asyncronous, isn't it?
Comment 171 Michael Leupold 2008-11-09 15:56:52 UTC
Still reproducible on trunk r881868 - however I guess this just holds true for filters using external programs (like spamassassin).
Comment 172 ra 2008-11-27 13:22:47 UTC
patch from comment#77 works for me (fetching mails from remote server via pop3s and local filtering through spamc and clamav).
Comment 173 ra 2008-12-03 15:16:56 UTC
I have to correct my statement above: The patch from comment#77 works somewhat as it indeed solves the lock but some incoming mails get duplicated.
Comment 174 cquike 2009-02-06 12:57:33 UTC
I have the same problem, the UI freezes (I am using version 1.10.4 KDE 4.1.4 Fedora 10). It happens scrolling the body of a message or writing a new message.
 I am not sure if it happens when it is checking for new mail, but it seems so.
 Here are a couple of stacks taken with pstack when the UI s frozen. The freezes lasts for 5s approx.

 pstack output 1:
------------------
Thread 2 (Thread 0x7ffdb6d9a950 (LWP 7083)):
#0  0x00000032208deaa2 in select () from /lib64/libc.so.6
#1  0x0000003c20122626 in ?? () from /usr/lib64/libQtCore.so.4
#2  0x0000003c20059852 in ?? () from /usr/lib64/libQtCore.so.4
#3  0x00000032214073da in start_thread () from /lib64/libpthread.so.0
#4  0x00000032208e62bd in clone () from /lib64/libc.so.6
Thread 1 (Thread 0x7ffdc790d800 (LWP 1519)):
#0  0x00000032208d7c67 in fchmod () from /lib64/libc.so.6
#1  0x0000003c2011e579 in QFSFileEngine::setPermissions ()
#2  0x0000003c200d3724 in QFile::setPermissions ()
#3  0x0000003ac9ed6699 in KSaveFile::open () from /usr/lib64/libkdecore.so.5
#4  0x0000003f9c7c2aa8 in ?? () from /usr/lib64/libkmailprivate.so.4
#5  0x0000003f9c7ced2d in ?? () from /usr/lib64/libkmailprivate.so.4
#6  0x0000003c20156764 in QMetaObject::activate ()
#7  0x0000003f9c7a8d5f in ?? () from /usr/lib64/libkmailprivate.so.4
#8  0x0000003f9c7aa970 in ?? () from /usr/lib64/libkmailprivate.so.4
#9  0x0000003f9c7ced74 in ?? () from /usr/lib64/libkmailprivate.so.4
#10 0x0000003c20156764 in QMetaObject::activate ()
#11 0x0000003f9ca07f2f in ?? () from /usr/lib64/libkmailprivate.so.4
#12 0x0000003f9ca08105 in ?? () from /usr/lib64/libkmailprivate.so.4
#13 0x0000003f9ca08287 in ?? () from /usr/lib64/libkmailprivate.so.4
#14 0x0000003f9ca082c9 in ?? () from /usr/lib64/libkmailprivate.so.4
#15 0x0000003f9ca0840d in ?? () from /usr/lib64/libkmailprivate.so.4
#16 0x0000003c20156764 in QMetaObject::activate ()
#17 0x0000003c2015c9cf in ?? () from /usr/lib64/libQtCore.so.4
#18 0x0000003c20151073 in QObject::event () from /usr/lib64/libQtCore.so.4
#19 0x0000003c219828dd in QApplicationPrivate::notify_helper ()
#20 0x0000003c2198a68a in QApplication::notify () from /usr/lib64/libQtGui.so.4
#21 0x0000003aca5fb60b in KApplication::notify () from /usr/lib64/libkdeui.so.5
#22 0x0000003c20142391 in QCoreApplication::notifyInternal ()
#23 0x0000003c2016e0d6 in ?? () from /usr/lib64/libQtCore.so.4
#24 0x0000003c2016a83d in ?? () from /usr/lib64/libQtCore.so.4
#25 0x000000322203779b in ?? ()
#26 0x00007fffcf961a20 in ?? ()
#27 0x00007fffcf961a28 in ?? ()
#28 0x00007fffcf961a10 in ?? ()
#29 0x000000000089cd80 in ?? ()
#30 0x0000003c2016a830 in ?? () from /usr/lib64/libQtCore.so.4
#31 0x0000000000000000 in ?? ()


pstack output 2:
-------------------
Thread 2 (Thread 0x7ffdb6d9a950 (LWP 7083)):
#0  0x00000032208deaa2 in select () from /lib64/libc.so.6
#1  0x0000003c20122626 in ?? () from /usr/lib64/libQtCore.so.4
#2  0x0000003c20059852 in ?? () from /usr/lib64/libQtCore.so.4
#3  0x00000032214073da in start_thread () from /lib64/libpthread.so.0
#4  0x00000032208e62bd in clone () from /lib64/libc.so.6
Thread 1 (Thread 0x7ffdc790d800 (LWP 1519)):
#0  0x000000322140e8db in open64 () from /lib64/libpthread.so.0
#1  0x0000003c200ecf22 in ?? () from /usr/lib64/libQtCore.so.4
#2  0x0000003c200d480a in QFile::open () from /usr/lib64/libQtCore.so.4
#3  0x0000003c200ed45a in QTemporaryFile::open ()
#4  0x0000003ac9ed64b2 in KSaveFile::open () from /usr/lib64/libkdecore.so.5
#5  0x0000003f9c7c2aa8 in ?? () from /usr/lib64/libkmailprivate.so.4
#6  0x0000003f9c7ced2d in ?? () from /usr/lib64/libkmailprivate.so.4
#7  0x0000003c20156764 in QMetaObject::activate ()
#8  0x0000003f9c7a8d5f in ?? () from /usr/lib64/libkmailprivate.so.4
#9  0x0000003f9c7aa970 in ?? () from /usr/lib64/libkmailprivate.so.4
#10 0x0000003f9c7ced74 in ?? () from /usr/lib64/libkmailprivate.so.4
#11 0x0000003c20156764 in QMetaObject::activate ()
#12 0x0000003f9ca07f2f in ?? () from /usr/lib64/libkmailprivate.so.4
#13 0x0000003f9ca08105 in ?? () from /usr/lib64/libkmailprivate.so.4
#14 0x0000003f9ca08287 in ?? () from /usr/lib64/libkmailprivate.so.4
#15 0x0000003f9ca082c9 in ?? () from /usr/lib64/libkmailprivate.so.4
#16 0x0000003f9ca0840d in ?? () from /usr/lib64/libkmailprivate.so.4
#17 0x0000003c20156764 in QMetaObject::activate ()
#18 0x0000003c2015c9cf in ?? () from /usr/lib64/libQtCore.so.4
#19 0x0000003c20151073 in QObject::event () from /usr/lib64/libQtCore.so.4
#20 0x0000003c219828dd in QApplicationPrivate::notify_helper ()
#21 0x0000003c2198a68a in QApplication::notify () from /usr/lib64/libQtGui.so.4
#22 0x0000003aca5fb60b in KApplication::notify () from /usr/lib64/libkdeui.so.5
#23 0x0000003c20142391 in QCoreApplication::notifyInternal ()
#24 0x0000003c2016e0d6 in ?? () from /usr/lib64/libQtCore.so.4
#25 0x0000003c2016a83d in ?? () from /usr/lib64/libQtCore.so.4
#26 0x000000322203779b in ?? ()
#27 0x00007fffcf961a20 in ?? ()
#28 0x00007fffcf961a28 in ?? ()
#29 0x00007fffcf961a10 in ?? ()
#30 0x000000000089cd80 in ?? ()
#31 0x0000003c2016a830 in ?? () from /usr/lib64/libQtCore.so.4
#32 0x0000000000000000 in ?? ()
Comment 175 Dana Whicker 2009-03-12 16:51:12 UTC
From window report popup:
Application: KMail (kmail), signal SIGSEGV
0x00000035718a7f81 in nanosleep () from /lib64/libc.so.6
[Current thread is 1 (Thread 0x7fd63c7fc800 (LWP 7455))]

Thread 2 (Thread 0x7fd62c944950 (LWP 7469)):
#0  0x00000035718deaa2 in select () from /lib64/libc.so.6
#1  0x0000003d5e522626 in ?? () from /usr/lib64/libQtCore.so.4
#2  0x0000003d5e459852 in ?? () from /usr/lib64/libQtCore.so.4
#3  0x00000035724073da in start_thread () from /lib64/libpthread.so.0
#4  0x00000035718e62bd in clone () from /lib64/libc.so.6

Thread 1 (Thread 0x7fd63c7fc800 (LWP 7455)):
[KCrash Handler]
#5  0x0000003d6baa35ef in ?? () from /usr/lib64/libkmailprivate.so.4
#6  0x0000003d6b983cfe in KMMainWidget::updateMessageActions () from /usr/lib64/libkmailprivate.so.4
#7  0x0000003d6b99abd5 in KMMainWidget::qt_metacall () from /usr/lib64/libkmailprivate.so.4
#8  0x0000003d5e556764 in QMetaObject::activate () from /usr/lib64/libQtCore.so.4
#9  0x0000003d5e551073 in QObject::event () from /usr/lib64/libQtCore.so.4
#10 0x0000003d5f1828dd in QApplicationPrivate::notify_helper () from /usr/lib64/libQtGui.so.4
#11 0x0000003d5f18a68a in QApplication::notify () from /usr/lib64/libQtGui.so.4
#12 0x0000003d60404deb in KApplication::notify () from /usr/lib64/libkdeui.so.5
#13 0x0000003d5e542391 in QCoreApplication::notifyInternal () from /usr/lib64/libQtCore.so.4
#14 0x0000003d5e56e0d6 in ?? () from /usr/lib64/libQtCore.so.4
#15 0x0000003d5e56a83d in ?? () from /usr/lib64/libQtCore.so.4
#16 0x0000003d5a43779b in g_main_context_dispatch () from /lib64/libglib-2.0.so.0
#17 0x0000003d5a43af6d in ?? () from /lib64/libglib-2.0.so.0
#18 0x0000003d5a43b12b in g_main_context_iteration () from /lib64/libglib-2.0.so.0
#19 0x0000003d5e56a79f in QEventDispatcherGlib::processEvents () from /usr/lib64/libQtCore.so.4
#20 0x0000003d5f21328f in ?? () from /usr/lib64/libQtGui.so.4
#21 0x0000003d5e540cb2 in QEventLoop::processEvents () from /usr/lib64/libQtCore.so.4
#22 0x0000003d5e540e3d in QEventLoop::exec () from /usr/lib64/libQtCore.so.4
#23 0x0000003d5e5432ed in QCoreApplication::exec () from /usr/lib64/libQtCore.so.4
#24 0x0000000000402b5b in _start ()


______________________________________________________
From .xsession-errors

klauncher(3160) KConfigGroup::readXdgListEntry: List entry MimeType in "/a1/home/danaw/.local/share/applications/mozilla-firefox.desktop" is not compliant with XDG standard (missing trailing semicolon). 
kdeinit4: preparing to launch /usr/bin/firefox
QObject: Do not delete object, 'unnamed', during its event handler!
kdeinit4: preparing to launch 
kwin: X Error (error: <unknown>[DAMAGE+0], request: XDamageDestroy[DAMAGE+2], resource: 0x1e0eda5)
kdeinit4: preparing to launch 
kded(3162): The kwalletd service has been disabled 
kded(3162): The kwalletd service has been disabled 
kded(3162): The kwalletd service has been disabled 
kded(3162): The kwalletd service has been disabled 
kded(3162): The kwalletd service has been disabled 
kded(3162): The kwalletd service has been disabled 
kded(3162): The kwalletd service has been disabled 
kded(3162): The kwalletd service has been disabled 
kded(3162): The kwalletd service has been disabled 
kded(3162): The kwalletd service has been disabled 
kded(3162): The kwalletd service has been disabled 
kded(3162): The kwalletd service has been disabled 
kded(3162): The kwalletd service has been disabled 
kded(3162): The kwalletd service has been disabled 
kded(3162): The kwalletd service has been disabled 
kded(3162): The kwalletd service has been disabled 
kded(3162): The kwalletd service has been disabled 
kded(3162): The kwalletd service has been disabled 
kded(3162): The kwalletd service has been disabled 
kded(3162): The kwalletd service has been disabled 
kded(3162): The kwalletd service has been disabled 
klauncher(3160) KConfigGroup::readXdgListEntry: List entry MimeType in "/a1/home/danaw/.local/share/applications/mozilla-firefox.desktop" is not compliant with XDG standard (missing trailing semicolon). 
kdeinit4: preparing to launch /usr/bin/firefox
QObject: Do not delete object, 'unnamed', during its event handler!
kwin: X Error (error: <unknown>[DAMAGE+0], request: XDamageDestroy[DAMAGE+2], resource: 0x1e0ee6f)
kmail(7455) KMReaderWin::message: Attempt to reference invalid serial number 90932 
kmail(7455) KMail::MessageListView::StorageModel::releaseMessage: Trying to release a message at row  241  that no longer exists in the folder 
kmail(7455) KMReaderWin::message: Attempt to reference invalid serial number 90933 
kmail(7455) KMReaderWin::message: Attempt to reference invalid serial number 90927 
kmail(7455) KMReaderWin::message: Attempt to reference invalid serial number 90930 
kmail(7455) KMReaderWin::message: Attempt to reference invalid serial number 90930 
kwin: X Error (error: <unknown>[DAMAGE+0], request: XDamageDestroy[DAMAGE+2], resource: 0x1e0ef3c)
kmail(7455) KMail::MessageListView::StorageModel::releaseMessage: Trying to release a message at row  239  that no longer exists in the folder 
kmail(7455) KMReaderWin::message: Attempt to reference invalid serial number 90927 
do_ypcall: clnt_call: RPC: Unable to receive; errno = Connection refused
kmail(7455) KMReaderWin::message: Attempt to reference invalid serial number 90925 
kwin: X Error (error: <unknown>[DAMAGE+0], request: XDamageDestroy[DAMAGE+2], resource: 0x1e0ef3f)
kmail(7455) KMail::MessageListView::StorageModel::releaseMessage: Trying to release a message at row  237  that no longer exists in the folder 
*** KMail got signal 11 (Crashing)
QObject: Do not delete object, 'unnamed', during its event handler!
KCrash: Application 'kmail' crashing...
kdeinit4: preparing to launch /usr/libexec/kde4/drkonqi
kwin: X Error (error: <unknown>[DAMAGE+0], request: XDamageDestroy[DAMAGE+2], resource: 0x1e0f04b)
kdeinit4: preparing to launch 
kded(3162): The kwalletd service has been disabled 
kded(3162) KWallet::Wallet::openWallet: Pass a valid window to KWallet::Wallet::openWallet(). 
kded(3162): The kwalletd service has been disabled 
kded(3162): The kwalletd service has been disabled 
kded(3162): The kwalletd service has been disabled 
kded(3162): The kwalletd service has been disabled 
kded(3162): The kwalletd service has been disabled 
kded(3162): The kwalletd service has been disabled 
plasma(3201)/libplasma Plasma::FrameSvg::resizeFrame: Invalid size QSizeF(-22, 27) 
plasma(3201)/libplasma Plasma::FrameSvg::resizeFrame: Invalid size QSizeF(0, 0) 
plasma(3201)/libplasma Plasma::FrameSvg::resizeFrame: Invalid size QSizeF(-22, 27) 
plasma(3201)/libplasma Plasma::FrameSvg::resizeFrame: Invalid size QSizeF(0, 0) 
QCoreApplication::postEvent: Unexpected null receiver
kdeinit4: preparing to launch 
kded(3162): The kwalletd service has been disabled 
kded(3162) KWallet::Wallet::openWallet: Pass a valid window to KWallet::Wallet::openWallet(). 
kded(3162): The kwalletd service has been disabled 
kded(3162): The kwalletd service has been disabled 
kded(3162): The kwalletd service has been disabled 
kded(3162): The kwalletd service has been disabled 
kded(3162): The kwalletd service has been disabled 
kded(3162): The kwalletd service has been disabled 
QCoreApplication::postEvent: Unexpected null receiver
klauncher(3160) KConfigGroup::readXdgListEntry: List entry MimeType in "/a1/home/danaw/.local/share/applications/mozilla-firefox.desktop" is not compliant with XDG standard (missing trailing semicolon). 
kdeinit4: preparing to launch /usr/bin/firefox
QGraphicsGridLayout::itemAt: invalid row, column 0, 0
QObject: Do not delete object, 'unnamed', during its event handler!
LoadPlugin: failed to initialize shared library /usr/java/jdk1.6.0_03/jre/plugin/i386/ns7/libjavaplugin_oji.so [/usr/java/jdk1.6.0_03/jre/plugin/i386/ns7/libjavaplugin_oji.so: wrong ELF class: ELFCLASS32]
QGraphicsGridLayout::itemAt: invalid row, column 0, 0
kwin: X Error (error: <unknown>[DAMAGE+0], request: XDamageDestroy[DAMAGE+2], resource: 0x1e0f085)
Comment 176 Michael Leupold 2009-03-12 22:20:53 UTC
(In reply to comment #175)
Dana, how is your crash related to the original bugreport?
Comment 177 Dana Whicker 2009-03-13 03:15:33 UTC
(In reply to comment #176)

KMail had frozen and I attempted to close the window using the top level window menu Close.  It said that KMail was not responding and asked whether to terminate.  I clicked Yes and I got this crash dump.

I think that I had only been selecting a message to read when it froze, but it is possible that I deleted a message.
Comment 178 Axel Braun 2009-08-30 19:11:53 UTC
(In reply to comment #169)
> Just to reiterate, for those who are too lazy to read a few pages up. The KMail
> backend is planed to be replaced by Akonadi for KDE 4.2 (last I heard). For now
> it still uses the same engine as 3.x, which means it still checks mail in the
> main thread.


As KDE 4.3 is out, and the problem is still a pain in the neck, may I ask what the new schedule is? Or is Akonadi not the solver?
Comment 179 Martin Steigerwald 2009-08-30 20:34:25 UTC
According to the following blog entry from Kevin it is in the works:

Kevin Ottens, KMail as components, Akonadi Mail Reader:
http://ervin.ipsquad.net/2009/08/20/kmail-as-components-akonadi-mail-reader/

As for a schedule, see the following comment from him - copied from the blog comments:

"I’m not the KMail maintainer and ultimately it is his decision. His current plan is to have an Akonadi based KMail officially in KDE for 4.5. We might have something working by 4.4, but I think he is definitely right to give it more time to mature before our user base at large switch to it."

I still thinks its ready, when its ready. And the only way to speed up the process is to help.
Comment 180 Björn Ruberg 2009-12-12 00:44:27 UTC
*** Bug 215154 has been marked as a duplicate of this bug. ***
Comment 181 Allan Sandfeld 2009-12-12 10:22:31 UTC
What is the status of this bug? Is any of the  current akonadi related changes going to change this and what is the timeframe for akonadi-based kmail (4.4?). Or is this bug now depending on another yet unassigned major refactoring of KMail?
Comment 182 Ferdinand Gassauer 2009-12-12 11:46:49 UTC
I usually do not experience hanging kmail (4.3.4) any more using IMAP on a stable connection

I could imagine a prablem related to broken (internet) connection.
Comment 183 Thomas McGuire 2009-12-12 12:46:54 UTC
> What is the status of this bug? Is any of the  current akonadi related 
> changes going to change this and what is the timeframe for akonadi-based 
> kmail (4.4?).
> Or is this bug now depending on another yet unassigned major refactoring of
> KMail?

This bug will go away once KMail is fully ported to Akonadi, as everything, including filtering, runs in background processes and the KMail GUI can't be blocked anymore. The Akonadi port of KMail currently happens in the akonadi-ports branch and is expected to arrive for KDE 4.5.
Comment 184 Axel Braun 2009-12-14 09:24:38 UTC
(In reply to comment #182)
> I usually do not experience hanging kmail (4.3.4) any more using IMAP on a
> stable connection
> 
> I could imagine a prablem related to broken (internet) connection.

Dont think so: I'm on a nice 16M DSL line, but when KMail fetches new mail, it is impossible to write a message: Nothing happens while typing, and slowly the letters drop in...
Comment 185 Björn Ruberg 2009-12-21 18:53:07 UTC
*** Bug 37149 has been marked as a duplicate of this bug. ***
Comment 186 ancow 2010-03-13 00:30:00 UTC
Just out of curiosity: why is this bug still maked as "new" when it has clearly been confirmed for years?
Comment 187 Pino Toscano 2010-03-13 00:35:24 UTC
(In reply to comment #186)
> Just out of curiosity: why is this bug still maked as "new" when it has clearly
> been confirmed for years?

Because NEW means "confirmed" and not "new bug" (which is UNCONFIRMED)?
Comment 188 markuss 2010-03-13 14:27:07 UTC
I've changed the version number, because the upcomping KMail 2.0 (which is the current trunk version) shouldn't be affected by this bug (because Akonadi does all the checking in the background in separate processes).

Not sure if I should also set the bug from NEW to ASSIGNED, because for the sake of simplicity KMail 2.x has its own category in Bugzilla and will be filed as "kmail2" and not "kmail" (similar to how the KAddressbook rewrite was handled).
Comment 189 Richard Hartmann 2010-05-14 16:44:41 UTC
According to http://thomasmcguire.wordpress.com/2010/05/14/akonadi-meeting-and-the-kde-sc-4-5-release/ , this bug will still be in KMail 2 when it releases.

I changed the version to SVN trunk.
Comment 190 Richard Hartmann 2010-05-14 16:49:28 UTC
According to http://thomasmcguire.wordpress.com/2010/05/14/akonadi-meeting-and-the-kde-sc-4-5-release/ , this bug will still be in KMail 2 when it releases.

I changed the version to SVN trunk.
Comment 191 Mike pina 2010-07-24 08:53:44 UTC
I get this no matter what I am doing.  In my case I launch KMAIL then I begin writing a new message and in variable within a minute everything freezes and I am toast I can no longer do anything.  I have left it for more than an hour and nothing.

KMAIL is useless for me now for more than two weeks!
Comment 192 quazgar 2010-07-24 10:03:24 UTC
(In reply to comment #191)
> I get this no matter what I am doing.  In my case I launch KMAIL then I begin
> writing a new message and in variable within a minute everything freezes and I
> am toast I can no longer do anything.  I have left it for more than an hour and
> nothing.

Hello Mike,
this sounds like a different bug.  Please file a new bug in the bug report system for this.
Comment 193 Oldřich Jedlička 2010-07-26 11:55:58 UTC
(In reply to comment #191)
> I get this no matter what I am doing.  In my case I launch KMAIL then I begin
> writing a new message and in variable within a minute everything freezes and I
> am toast I can no longer do anything.  I have left it for more than an hour and
> nothing.
> 
> KMAIL is useless for me now for more than two weeks!

I've got the same problem, but it is really unrelated to this thread. In my case it was freezed akonadi and restarting it helped (kill it all and use akonadictl to start it again).
Comment 194 MR 2010-08-24 09:39:04 UTC
Please, tell me that you are not serious about this bug?! I stumpled over this bug report because I am experiencing the same bug and thought about writing an bug report. This bug is really annoying and not being fixed for 8 years and still not fixed in kmail2, kind of ridiculous. Isn't it? My Mailbox is growing and I use several filters to sort incoming mail. Please do something about this!
Comment 195 Oldřich Jedlička 2010-08-24 22:48:05 UTC
(In reply to comment #194)
> Please, tell me that you are not serious about this bug?! I stumpled over this
> bug report because I am experiencing the same bug and thought about writing an
> bug report. This bug is really annoying and not being fixed for 8 years and
> still not fixed in kmail2, kind of ridiculous. Isn't it? My Mailbox is growing
> and I use several filters to sort incoming mail. Please do something about
> this!

What version of kmail are you using? I'm just curious, because kmail2 wasn't officially released yet and I plan to try it as soon as it goes out with KDE release.
Comment 196 Kai Uwe Broulik 2010-08-30 22:57:38 UTC
I don‘t know which kind of “bug” is described here, when I click on “check for new mail” I can browse folders and mails, and even start typing a new email?
Or does it only occurr when it is automatically fetching new mail
Comment 197 Unknown 2010-08-31 18:02:09 UTC
Hello!

On Monday 30 August 2010 22:58:39 KaiUweBroulik2@hotmail.com wrote:
> https://bugs.kde.org/show_bug.cgi?id=41514
 
> --- Comment #196 from  <KaiUweBroulik2 hotmail com>  2010-08-30 22:57:38
> --- I don‘t know which kind of “bug” is described here, when I click on
> “check for new mail” I can browse folders and mails, and even start typing
> a new email? Or does it only occurr when it is automatically fetching new
> mail
I worked also on the bug 77862. It might be the one for you, 
You only need to answer the question: Do you change/get the Ip-Address at the 
time you get the problem? If "yes", it is the second bug. Let me know.
Comment 198 MR 2010-09-01 10:08:19 UTC
Sorry for my delayed answer. I am using KMail1, my comment to KMail2 is based on the link posted above by Richard Hartmann.
Comment 199 maniandram 2010-12-23 12:38:47 UTC
This bug seems to be fixed.(At least in KMail 1.13.5)
Comment 200 Axel Braun 2010-12-23 14:35:38 UTC
(In reply to comment #199)
> This bug seems to be fixed.(At least in KMail 1.13.5)

Definitely not.....
Comment 201 Dhaivat Pandya 2011-03-13 16:59:16 UTC
What is UP with this bug? It is by far the most hated, yet no one seems to care about since the past, what, 9 years?!
I'm willing to try to fix it, since the solution doesn't seem difficult (QTimer or a QThread, none of which are hard to implement), or is there a more complicated problem that I'm missing?
Comment 202 Dennis Schridde 2011-03-13 17:23:25 UTC
(In reply to comment #201)
> I'm willing to try to fix it, since the solution doesn't seem difficult (QTimer
> or a QThread, none of which are hard to implement), or is there a more
> complicated problem that I'm missing?
1) Threads have to be synchronised, information has to be exchanged between them, etc. It is doubtful that in a complex piece of software this task is simple.
2) The solution of the KDE-PIM team is called Akonadi and being worked one since several years. It is a client/server system for PIM management and will hopefully be released this decade. ;)
Comment 203 RussianNeuroMancer 2011-06-11 01:16:01 UTC
Isn't it's fixed in KDE PIM 4.6?
Comment 204 Christoph Feck 2011-07-11 03:23:37 UTC
*** Bug 274004 has been marked as a duplicate of this bug. ***
Comment 205 krienke 2011-07-14 12:03:34 UTC
I can report from my tries with kde 4.6.5 and kmail2 on my openSuSE 11.4 system (icore5 with 8GB RAM). When kmail2 is looking for mail in the background it becomes slow as hell. I wanted to write a new mail while kmail2 was working through my four imap servers in order to find new mail. 

When typing the typed letters arrived 3 seconds after that I hit the keys. So there is a big delay. In between I reverted from kmail2 back to kmail1 and here I do not have this trouble using the same imap servers. kmail1 just works fine, no big delays as with kmail2. However kmail1 is still much slower than thunderbird querying the very same four imap servers.

Rainer
Comment 206 Oldřich Jedlička 2011-07-14 14:50:12 UTC
(In reply to comment #205)
> I can report from my tries with kde 4.6.5 and kmail2 on my openSuSE 11.4 system
> (icore5 with 8GB RAM). When kmail2 is looking for mail in the background it
> becomes slow as hell. I wanted to write a new mail while kmail2 was working
> through my four imap servers in order to find new mail. 

Your problem is unrelated to reported problems that started with kmail 1 - slowness/"freeze" caused by running filters. You are probably referring to slowness of fetching mails - something similar to bug 277597, which I observe with POP3 account, but you have it with an IMAP account.
Comment 207 krienke 2011-07-14 16:19:52 UTC
(In reply to comment #206)

> Your problem is unrelated to reported problems that started with kmail 1 -
> slowness/"freeze" caused by running filters. You are probably referring to
> slowness of fetching mails - something similar to bug 277597, which I observe
> with POP3 account, but you have it with an IMAP account.

My Problem ts not the speed of fetching mail that does not work as before, but the speed of typing a new mail while fetching mail automatically. This is where words that I type appear some seconds later in the editor window. So in a sense kmail2 freezes the UI to some degree while fetching new mail which is what the OP said. The difference is really that he was talking about kmail1 and am talking about kmail2.

Should I start a new Bugreport?
Comment 208 András Manţia 2011-09-22 05:54:06 UTC
Stay tuned, this bug will go away soon. I will not close it, but let the one who implemented the new filtering backend do it once it is well tested.
Comment 209 Arne Babenhauserheide 2011-09-22 07:22:34 UTC
*Happy*!
Comment 210 András Manţia 2011-09-29 12:58:29 UTC
Closing now. Fixed by Tobias Koenig in master, fix will be in KDE 4.8.
Comment 211 Anders E. Andersen 2011-09-29 13:07:24 UTC
In other news, a new ice rink is opening in Hell this weekend.

GJ!