| Summary: | KMail freezes the UI when checking for new mail | ||
|---|---|---|---|
| Product: | [Unmaintained] kmail | Reporter: | A T Somers <andre> |
| Component: | general | Assignee: | kdepim bugs <kdepim-bugs> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | adam, amantia, ana, andreas-stangl, arne_bab, aspotashev, axel.braun, bluedzins, bugs, cerebro84, christiand59, cquike, cyberbeat, darius, dhaivatpandya, didier.herisson, dkolars, dominik.geyer, Ernestjw, esigra, finex, foontala, gassauer, gschintgen, heri+kde, ict, ismail, joerg, jowenn, jtamate, KaiUweBroulik2, kamikazow, kapaneus, kaplun, karaluh, kbug, kde, kde, kdebugs, kevin, knt, krienke, kyron, lemma, maniandram01, Martin, mhlavink, michaelpina, moron, mroeben, oldium.pro, outrage, pascal+kde, paulpach, ptaylor, quazgar, ralphdewitt, richih-kde, robertg.123, russianneuromancer, r_a, shahn, shai, skatemaster, steffen.schloenvoigt, sven.burmeister, symbiont, tokoe, ub1x, uplawski, vaugustin, vendion, wolfram.wagner, xenoterracide, yhager |
| Priority: | NOR | Keywords: | triaged |
| Version: | SVN trunk (KDE 4) | ||
| Target Milestone: | --- | ||
| Platform: | RedHat Enterprise Linux | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | 4.8.0 | |
| Sentry Crash Report: | |||
| Attachments: |
Test patch to rule out sorting.
Filter to show lock in pipe Idea to solve that lock - ask for feedback |
||
|
Description
A T Somers
2002-04-23 10:23:18 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> 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?
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? 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) 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
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 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...) 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. 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?
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 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. 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.
*** Bug 52192 has been marked as a duplicate of this bug. *** 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. 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. 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... 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. 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. 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).
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);
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).
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. 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 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. 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.
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 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.
*** Bug 61170 has been marked as a duplicate of this bug. *** 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. 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. *** Bug 62006 has been marked as a duplicate of this bug. *** *** Bug 62849 has been marked as a duplicate of this bug. *** 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 *** Bug 63559 has been marked as a duplicate of this bug. *** 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. 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. *** Bug 46654 has been marked as a duplicate of this bug. *** 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). 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. 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. 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. 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 Ditto with SA 2.62 and up to and including kde 3.2.0 rc1 *** Bug 77957 has been marked as a duplicate of this bug. *** Still present in KDE 3.2.1.. SA is still blocking kmail. 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) *** Bug 81458 has been marked as a duplicate of this bug. *** *** Bug 37054 has been marked as a duplicate of this bug. *** 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 ;-) Still happens in KDE 3.2.3 and SA 2.63 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). 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. :) Yes, someone please thread these functions! 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 :) 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é 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? 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/) 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?! 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 ? ;) 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. *** Bug 90043 has been marked as a duplicate of this bug. *** *** Bug 89166 has been marked as a duplicate of this bug. *** *** Bug 91286 has been marked as a duplicate of this bug. *** 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. 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 *** Bug 96500 has been marked as a duplicate of this bug. *** 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. 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) *** Bug 98336 has been marked as a duplicate of this bug. *** Add kmail-devel as per Ingo's request. (Hopefully I understood correctly). 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. 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. 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. 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. during filtering my 1.7 P4 cpu is at 100%, investigating kontact performance issues as well as renicing filtering subprograms might help too. 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)
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
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 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. 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] Problem is still there for POP in KDE 3.5 #81 : Have you read comment #79 ? 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. 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. 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. Concerning #85 I quite agree. It peeves me quite often. 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. 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. 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. 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. 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. 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? 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. 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 Oh, and my CPU load is just a few percent after I killed KMail and started it from konsole, KMail is usually responsive, although it doesn't actually finish loading any of my folders. 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. this problem started to apear when i starated to use pipe through spamc 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 *** Bug 123763 has been marked as a duplicate of this bug. *** 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. 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) 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 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. 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... It was not the Trash folder... problem back again... Noticed that i have Search folders... I suspect them instead. 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. 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. 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 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. 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. > 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.
Sure, but bogofilter is said to be magnitudes faster than spamassassin, so with bogofilter this problem should be much less annoying. 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. WE KNOW!!!!!!! Sigh... 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
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 ? 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.
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.
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 blocking also happens when moving messges from one folder to the other or when importing messages (from thunderbird, for example). *** Bug 122164 has been marked as a duplicate of this bug. *** This freeze has become even worse with spamassassin enabled (NOT via spamd). 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. ;-) 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. *** Bug 136615 has been marked as a duplicate of this bug. *** 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 *** Bug 137546 has been marked as a duplicate of this bug. *** Freeze make kmail difficult to use on a machine that's not running all day long..... 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 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 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. 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. *** Bug 141852 has been marked as a duplicate of this bug. *** 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 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.. 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. 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 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. 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? 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... 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. 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. *** Bug 121207 has been marked as a duplicate of this bug. *** Thanks to Comment #142, I have also switched from spamassassin to CRM114 and there is a marked improvement. Re: Comment #145 - ...except that CRM114 doesn't work well enough for me so I've gone back to using spamassassin. *** Bug 144091 has been marked as a duplicate of this bug. *** 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. 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. The problem comes from using an external application to filter spam, like bogofilter. KMail becomes unresponsive, even on modern hardware. 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. 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?! 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! Might I suggest that the status is changed to unassigned then? Re: Comment #153 So much for "Fix it yourself"; what happens to bug 97925? The patch is there sitting since 2005, still awaiting. I would like to second Somers' suggestion. Status is should be unassigned. 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. 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. 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. *** Bug 147928 has been marked as a duplicate of this bug. *** Same thing's with kopete when getting messages. 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. 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 ;) 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?). 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" ;) *** Bug 159610 has been marked as a duplicate of this bug. *** Same here with Gmail's IMAP when getting "All Mail" (a huge folder, I've had it since 2005). 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. 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 akonadi is going to be asyncronous, isn't it? Still reproducible on trunk r881868 - however I guess this just holds true for filters using external programs (like spamassassin). patch from comment#77 works for me (fetching mails from remote server via pop3s and local filtering through spamc and clamav). 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. 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 ?? () 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) (In reply to comment #175) Dana, how is your crash related to the original bugreport? (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. (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? 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. *** Bug 215154 has been marked as a duplicate of this bug. *** 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? 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. > 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.
(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... *** Bug 37149 has been marked as a duplicate of this bug. *** Just out of curiosity: why is this bug still maked as "new" when it has clearly been confirmed for years? (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)? 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). 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. 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. 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! (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. (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). 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! (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. 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 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. Sorry for my delayed answer. I am using KMail1, my comment to KMail2 is based on the link posted above by Richard Hartmann. This bug seems to be fixed.(At least in KMail 1.13.5) (In reply to comment #199) > This bug seems to be fixed.(At least in KMail 1.13.5) Definitely not..... 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? (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. ;) Isn't it's fixed in KDE PIM 4.6? *** Bug 274004 has been marked as a duplicate of this bug. *** 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 (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. (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? 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. *Happy*! Closing now. Fixed by Tobias Koenig in master, fix will be in KDE 4.8. In other news, a new ice rink is opening in Hell this weekend. GJ! |