Summary: | crash with new copy folder function | ||
---|---|---|---|
Product: | [Unmaintained] kmail | Reporter: | m.wege |
Component: | disconnected IMAP | Assignee: | kdepim bugs <kdepim-bugs> |
Status: | RESOLVED FIXED | ||
Severity: | crash | ||
Priority: | NOR | ||
Version: | 1.9.6 | ||
Target Milestone: | --- | ||
Platform: | unspecified | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: | |||
Attachments: | message that seems to have caused the crash |
Description
m.wege
2007-04-05 11:37:42 UTC
Same crash exists in KDE 3.5.7 on kubuntu Can you pinpoint the message which produces the problem? My guess is that this is a message with a big attachment. Please check that. I am not quite sure how to do this. It is a large folder with subfolders. Will it be the last message in the last folder? Or is there a logfile, where I can find out? It seems like it crashed after creating a subfolder or when reading/writing the first message. I can export that folder, since it only contains a mailing list A mailinglist is probably to big as an attachment for bugzilla. Please try to narrow down the problem a litte more: Manually create a folder and copy some messages of your mailinglist folder to there. Then try to copy your new folder to somewhere else. -If it doesn't crash, add some messages from the original folder to the mailinglist folder and try again. -If it does crash, remove as many messages from that folder as possible until it does not crash anymore This way, it should be possible to know which message causes the crash or if even copying empty folders crashes. If it does not crash at all with this method, it is probably related to subfolders. Try to manually recreate the folder structure, with one message only in each folder, and try to copy the root folder of your manually created folder structure. I hope I could explain what I mean and I hope you track the problem down. In the end, if this problem is not related to a special message, I need a report like: Create folder A, with subfolder B and C. Put a message in folder B only and try to copy folder A to somewhere. It will crash then. ok, I think I have isolated the message. After removing it, there is no crash. I also noticed there is no crash when copying vom DIMAP to local folder. The crash only happens when copying from DIMAP to DIMAP. There is another suspicious message, one of the empty ones cause by the famous DIMAP-crashing bug. But after deleting the crash still appeared. Just to be sure, here is the content of that empty mail. X-UID: 8 Status: RO X-Status: RC X-KMail-EncryptionState: N X-KMail-SignatureState: N X-KMail-MDN-Sent: Created attachment 20670 [details]
message that seems to have caused the crash
Without this stopper message the copy function ran for a while without crashing. But it seems to take a lot of system resources (my message base is 1,2GB) and finally froze the first of Kmail, then the whole KDE, it took a very long time to get a console. After nearly an hour I restarted X because it was unknown to me if the copy procedure was still going on. Copying messages is a blocking function, and with 1.2GB it indeed takes long. However, it shouldn't hang X or KDE. Maybe this was what I mentioned earlier: A message with a big attachment taking all memory, thus slowing down the system. I have no DIMAP, so I can't reproduce unfortunately. I'll tell the original author though. SVN commit 688956 by vkrause: Don't crash when copying/moving a folder with a corrupt IMAP cache. CCBUG: 143869 M +7 -0 kmcommands.cpp --- branches/kdepim/enterprise/kdepim/kmail/kmcommands.cpp #688955:688956 @@ -1950,6 +1950,13 @@ idx = srcFolder->find(msgBase); assert(idx != -1); msg = srcFolder->getMsg(idx); + // corrupt IMAP cache, see FolderStorage::getMsg() + if ( msg == 0 ) { + KMessageBox::error( parentWidget(), i18n("Corrupt IMAP cache detected in folder %1. " + "Copying of messages aborted.").arg( srcFolder->prettyURL() ) ); + deleteLater(); + return Failed; + } } if (srcFolder && mDestFolder && >Don't crash when copying/moving a folder with a corrupt IMAP cache.
>CCBUG: 143869
Volker: Why only CCBUG and not BUG? Was this not completely fixed?
SVN commit 689500 by vkrause: Backport commits 688956 and 689037 from enterprise branch (crash fixes for folder moving). I'm aware that this breaks the message freeze, but an untranslated error message seems to be a better option than a potentially dangerous crash. BUG: 143869 M +7 -0 kmcommands.cpp M +6 -0 kmfoldertree.cpp --- branches/KDE/3.5/kdepim/kmail/kmcommands.cpp #689499:689500 @@ -1935,6 +1935,13 @@ idx = srcFolder->find(msgBase); assert(idx != -1); msg = srcFolder->getMsg(idx); + // corrupt IMAP cache, see FolderStorage::getMsg() + if ( msg == 0 ) { + KMessageBox::error( parentWidget(), i18n("Corrupt IMAP cache detected in folder %1. " + "Copying of messages aborted.").arg( srcFolder->prettyURL() ) ); + deleteLater(); + return Failed; + } } if (srcFolder && mDestFolder && --- branches/KDE/3.5/kdepim/kmail/kmfoldertree.cpp #689499:689500 @@ -2031,6 +2031,12 @@ } } + // de-select moved source folders (can cause crash due to unGetMsg() in KMHeaders) + if ( move ) { + doFolderSelected( indexOfFolder( destination ), false ); + oldCurrent = currentItem(); + } + // do the actual move/copy for ( QValueList<QGuardedPtr<KMFolder> >::ConstIterator it = sources.constBegin(); it != sources.constEnd(); ++it ) { KMFolder* source = *it; I have now KDE 3.58 running and tried to use the copy function again. It now crashes with a different mail (without any backtrace, kmail just disappears). I send the mail to someone privateately for testing, where it stopped). One characteristic of the mail is that it is big (36MB), so there may be a memory problem. It also seem that the longer the copy function is running, it is becoming slower. >One characteristic of the mail is that it is big (36MB), so there may be a memory problem. It also seem that the longer the copy function is running, it is becoming slower. This is not a problem specific to the copy function, KMail generally has problems with big messages, see bug 110574. Closing this bug report again, see the other one. |