Bugzilla – Bug 1054205
Kmail corrupts indexes and requires cache clearing on a regular basis
Last modified: 2019-07-07 20:49:04 UTC
Created attachment 736998 [details] output of akonadiconsole Kmail qualifies as Kmail 5.5.2 The setup is one pop and one IMAP account. The symptoms manifest nearly only with the pop one. The mails are not shown, a script in the lower part claims something like multiple merge candidate. The folder hit by this problem migrates in a random way, once a folder is compromised it stays unreadable. Eliminating folders do not help. The problem will appear again with a newly created folder. I join a bug output of akonadiconsole. Note: akonadictl stop akonadictl fsck (command runs in a apparently abortive mode, only rarely it gives any feedback. It just runs and stay open without output or return to prompt). akonadictl vacuum is practically alway in this state and is apparently not functional. The above problem has been reported also by other users. It seems that also this is due to a compromised index or cache. There is a constant problem of "ghost messages" that have the right subject but the wrong content is then displayed (with "multiple merge candidate error diplayed". Unread messages in this condition will stay unread. They may persist also a flush of cache, after however they will be unread and duplicated. If opened, after cache clearing in akonadiconsole all doubles do open correctly. When running "elminate duplicates" some will, sometimes, some will not be eliminated. Can be eliminated however manually. Before cache clearing they cannot be eliminated, not even manually. Terminal: when restarting with akonadiconsole restart, the output gives besides the normal feedback following error: ---snip----- Connecting to deprecated signal QDBusConnectionInterface::serviceOwnerChanged(QString,QString,QString) org.kde.pim.maildispatcher: Item 68956 does not have the required attribute Address. org.kde.pim.maildispatcher: Item 68955 does not have the required attribute Address. org.kde.pim.maildispatcher: Item 68954 does not have the required attribute Address. Pass a valid window to KWallet::Wallet::openWallet(). ----snap------ There is finally a very odd behavior during indexing. In the folder "drafts" - here bozze because in Italian - where a multitude (up to thousand and more) messages appear, then disappear again as they populate the indexes). As if a magic and abusive filter entry filters all to drafts and then from there in other folders. Often when this happens a bunch (about 20 messages) remain in drafts. Manual triggered filtering (apply all filters) will then attribute generally all but one message into the respective correct folders. An elimination and recreation of drafts folder is not possible (greyed out) - this may be a wanted behavior. Kmail qualifies as Kmail 5.5.2 I have this problem on several computers. However the gravity varies greatly between user and user and the user with mixed pop/imap folders / accounts seem to suffer this problem much more often then only pop or only imap.
Created attachment 737000 [details] full output that you get when running aconadictl restart just to help to understand, found more errors down the output.
As discussed on the mailing list and mentioned in bug#1053525, the problems apparently are fixed by an upstream commit in later kmail versions: https://cgit.kde.org/kmail.git/commit/?id=43f2cde61f98317eb13d98222a57bc6df323a308 I'll submit an update to 42.3 with that patch.
*** Bug 1053525 has been marked as a duplicate of this bug. ***
This is an autogenerated message for OBS integration: This bug (1054205) was mentioned in https://build.opensuse.org/request/show/530034 42.3 / kmail
After a few days now, I have the first error (limited to the mixed imap / pop account). You need furthermore special conditions to trigger that. a) the machine had an uptime of several days and was several times suspended to disk with Kontact open. b) during the wake up of the machine there is new pop mail comming in c) you are during the wakeup on the same folder where the mail comes in and(!) perform some read actions on other messages. d) I had finished writing a new message and it was in the process of sending when the new mail came in. I got there one error now that I will repair with akonadiconsole, but I wanted to wait for your feedback if you like to have some logs etc. The error message is: Unable to fetch item from backend (collection -1) : Unable to retrieve item from resource: [LRCONFLICT] Resource akonadi_maildir_resource_0 tries to modify item 6832 () (in collection 46) with dirty payload, aborting STORE. All the other folders and a bunch of 30 or more messages where filtered correctly and made no problems. The message that is hit by this error is duplicate and stays "unread". The content of the message is however visible. special behaviour I noted: I was also writing and sending an answer right in the very moment when that happened. The message (outgoing) appeared in the folder "in arrival" but was then sent correctly, and put into "send message" folder correctly. I have the impression that this was somehow related.
I updated to the latest package of the repo of Wolfgang. As a result the system crashes again and the filtering process has become unreliable. Unfortunately I cannot revert back because the original working package has disappeared from the repo. If you want to confirm that changes to the package are responsible for this, you may make the former package available again for alternative install. That should restore stability. P.S. System load and temperature seem higher now then before.
I did install the latest package from Wolfgangs repo as soon as it became available. I had today again a total system crash. The frequency is however low. The crashes are related, one to one, to the use of kmail in the account where imap and pop are mixed. They appear practically solely when I compose(!) and email, never when I read email. In this case I did compose an email as a reply with the pop account and as there was a lot of redundant text, I selected this text with the mouse. Then the crash was triggered. So if this helps you, the best package I had was the first installed, but maybe I was only lucky in the period that the crash was not triggered by some action. The current status is better then the status of the last package because filtering works correctly. But I am definite, this is triggered by the composer of kmail in mixed asset imap/pop and seems to be related to the amount of text written or apparently also when I select with the mouse a lot of text. Hope that helps somehow.
I have now installed version 17.04.2-8.3 After the install I have now a somewhat non working filter function, that is, filters are applied to the messages, but then the messages stay in arrival, unfiltered. It is then possible to filter the messages applying the filters manually, but at a price of a very slow filtering process and of a very high system load (with temperatures reaching the throttle level. This is true for both the user with imap/pop (and filtering mailing lists and for the pure pop user. If desired I can switch on the filter protocol and post an attachment. I did not experience black screens with this version up to now, but I also did not yet try multiple suspend to disk actions.
I have had another crash today and can give more details about the macroscopic behaviour of the machine prior to crashing. a) the crash requires kontact/kmail to be open. b) it seems that it is important to have IMAP and POP mixed as accounts c) you need to have a composer window of kmail open full screen mode (it is a 12" here). d) during the writing progress the prodromic symptom is the appearance of micro blackouts of less then a second of the screen during typing. These I can confirm, happen always when you hit the space tab as it seem. (As I am writing "blind" swiftly, it is difficult to sense which stroke is the right one, so I think(!) it is when I hit space). e) the crash happens, or with very large text and long persistent writing, or and especially, if whatever text is selected to do a copy and paste. Then the crash is immediate.
openSUSE-RU-2017:2681-1: An update that has three recommended fixes can now be installed. Category: recommended (moderate) Bug References: 1013687,1053540,1054205 CVE References: Sources used: openSUSE Leap 42.3 (src): kmail-17.04.2-3.1
This continues with the current Kontact. I opened a bug on kde (because kde segfaults all the time) but I do not know if KDE bugzilla will follow up on it since the Leap version is very old and they close all below 5.12 https://bugs.kde.org/show_bug.cgi?id=388932 I will add an attachment with a gdb output of a segfault. Feel free to close it if you do not think this is a Leap problem. However, since probably upstream will close it and we will have 42.3 still for a year, maybe it is of interest. What it does: open Kontact, use it for a while. Then you find out that a) mail is not retrieved any more. b) when you close and restart kontact, the first start segfaults (see attachment) c) the second restart succeeds. However you have - old messages appearing as unread - erases messages (even erased long time ago) reappear! - database may be damaged reporting items without RID and "dirty without RID". - also "unable to fetch from database error" may occur and require clear cache of the local folder hit with akonadictl. What the software should do: not crash, not to make messages change status or even reappear.
Created attachment 758495 [details] GDB output of typical segfault of Kontact. join a gdb output. Konqui does pup up regularly but just reporst segaulf without infos. May not be perfect, I am still working on getting better results with gdb.
This seems to be fixed upstream for Leap 15 (still need to use it on a regular basis for more time). It was still valid for 42.3 when upgrading. Segfaults after restart of Kontact are still there in 15 but with a lower frequency. Indexes seem to suffer less though.
as indicated in the last comment, seems to be fixed upstream. I had recently a machine with 42.3 under my hands were the problem did not present, although the machine had all same "symptoms" as the others I had seen. As there are: The filters are all broken and do not recall any of the destination folders (this behavior I observed it on 4 different machines). It seems to be that this could be a fruit of a former version upgrade? Some messages are left without date, especially if set to be eliminated by "scadenza" (validity?) if set in the folder. They then gather at the end of the message list and have to be eliminated manually. So currently it seems solved... as long as you do not deem the above as part of the problem. Complete cleanups were not necessary on the aforementioned machine.
this is valid for an out of support version. As of 15.1 Leap this does not produce anymore. Closing therefore.