Today I found some time and installed Leap on a spare SSD using setup defaults where possible (basically the same procedure i performed on my virtual test system).
Thus i’ve immediately updated from initial installation to the latest versions of Plasma, KF5 and KDE Applications. But then, on the first start of KMal the issue appeared (Akonadi not operating correctly, KMail blocked with grey shadowed screen, the Details button does nothing).
So a fresh minimal system on the real hardware results in crashing Akonadi resources with malloc error, same (and even larger) install on virtual system works without issues. What do we learn from this? A curious hardware related issue, e.g. with Qt 5.6 on AMD multi-core systems with 16 GB RAM? Arrghhh!
BTW, I also tested the /tmp wiping and couldn’t come to a stable and really reproducible situation, so this may be a misleading thing.
But didn’t you say you have the same problem on a fresh user account?
I can confirm that the Akonadi connection issue appears on new users as well (on existing prod and fresh test system), if it’s running on my real hardware. These are my observations.
Hm, maybe a microcode update issue?
There were some problems with this in the past (restricted to certain AMD CPUs), but those prevented the system from booting at all.
Still, I would try to disable it by adding “dis_ucode_ldr” to the kernel boot options, maybe the updated microcode for your CPU is buggy.
I.e. press ‘e’ at the boot menu, search for the line starting with “linux” or “linuxefi”, and append the option at the end, then press F10 to boot.
This doesn’t modify your system at all, so is harmless to test.
Also check that ucode-amd is installed in the first place, normally this microcode update is supposed to fix bugs in the CPU’s microcode.
Well, I think we are all guessing at the moment, thanks for your time and suggestions.
I’m going mad, but after the first boot including “dis_ucode_ldr” KMail + Akonadi were OK - and that survived for the next two reboots and nearly the whole day of working with the system. But in the evening the akonadi imap resource crashed with the well-known malloc error. All following reboots came up with the same result (malloc error in an Akonadi resource), regardless of the use of the kernel boot option.
It seems the microcode doesn’t make a difference. This anomaly seems to be very deeply hidden in <whatever>. As soon as I have some time I’ll try to get some debug info of this crash - maybe it points us to the right direction.
I also have a system with AMD and 16 gigs of memory. I can believe that is related to the problem. I tried the dis_ucode_ldr fix and it had no effect. I don’t think the microcode is the issue, because I can reliably solve the problem by logging out of the Plasma shell and logging back in. On the new login, the akonadi problem is fixed but the process list shows two instances of the Plasma shell one of which is stopped and two instances of akonadictl. The process numbers show that one instance of the Plasmashell and one of akonadictl were started during the original boot. I can (and do) terminate the first instance of akonadictl with no effect on the system but have to kill the first instance of the Plasmashell, again with no effect on the system. In general, the system will then run for days with no problems although very occasionally the panel will stop responding.
Meanwhile I’m quite sure that we are barking up the wrong tree by talking about Akonadi or the KDE Applications in this thread!
As part of the preparations to start debugging the malloc errors in Akonadi resources, that seem to be related to the Akonadi connection issues, i setup a full Leap on my spare SSD (same installation i would do for a normal prod system). During fine tuning the config the system started to behave somewhat unusual (e.g. lagging responses, Favourites in Dolphin sidebar disappeared and reappeared after a while) but all without any apparent reason. Inspecting the .xsession-errors-:0 I found this:
Akonadi was not running at this time, it wasn’t configured and no Akonadi dependent application was ever started before in this system.
So to me it’s more likely that we’re facing an issue maybe in Qt 5.6 (or even in Plasma or the KDE Frameworks, can’t distinguish as all of these are upgraded together). My justification is the fact that Qt 5.5 and the previous Plasma + KDE Frameworks releases are running stable on this hardware in a nearly identical setup.
Are there any changes introduced in Qt 5.6 that might result in such malloc errors?
All in all this is one of the bugs i hate the most: Happens only on selected hardware, sporadic occurence, almost unclear origin.
There are of course many changes in Qt 5.6…
And this might even be a bug in gcc or glibc.
Qt 5.6.1 has been released yesterday, maybe this would work better?
The version in KDE:Qt5 has been updated already, just needs some time until all packages have been built and published.
Thank you for pointing me to the new Qt release that’s now available in the repo and installed - but with no success.
The first start came up with the everlasting malloc error. This time after an additional update i forgot to implement before. KDE PIM was still on version 4.1.4 and worked fine, even with the latest Qt installed. After the update to KDE:Applications 16.04.1 -> malloc crash. OTOH, using PIM 4.1.4 with Qt 5.6.x and KF 5.x is no solution as I discovered the same malloc error in another KDE module without running Akonadi at that time.
Now I added the information from this thread and results of our testings to the mentioned bug.
But it should be really hard to reproduce this issue, because everything is running flawlessly if used in any type of virtualizing environment (including debuggers).
Thanks for the info, i’ll try this soon. OTOH, i’m not very confident that it solves the issue on my system as the malloc error also occured without running Akonadi, in this case it happened in kded.
Good news: Yesterday I updated all packages in my still existing test installation (on real hardware, no virtual system) to the currently available versions. And to my surprise, everything is working since then. I’m using this environment since yesterday and Akonadi and all related applications are operating as expected.
Does anyone else also find that stuff working now?
There’s one issue remaining (or a new one) for me: The akonadi_imap_resource occasionally gives me a SEGFAULT - somthing I could also observe on my old working environment based on Qt 5.5. Just installed the debug packages…
I’m still having the same problem. As far as I can tell, all my packages are up to date. From time to time a random reboot would work fine, but then the problem would reassert itself on the next reboot. This has been my experience from the beginning.
With the latest update i can reboot and see Akonadi and KMail start normally. But after some time (and some intensive usage) one of the akonadi_imap_resource processes crashes. And after some more runtime any other KDE processes starts crashing. All without my beloved malloc error in .xsession-errors but instead with a SEGFAULT message. This happens regularly and makes the system unusable for daily work.
On the same hardware with Qt 5.5 and dependent packages everything is running ok for me.
Interesting. On that last reboot, KOrganizer did start normally. KMail didn’t start. When I reopened KOrganizer (almost immediately) it showed Akonadi down as did KMail when I started it.
I would suggest that Akonadi has never really worked at least consistently or up to its described potential. Recognizing, however that it is a work in progress. This is not a package that is really ready for prime-time. At some point the whole Kontact suite went off the rails but is coming back. When it works which of late is more and more it is a worthy PIM.
I updated KDE yesterday and experienced Kontact starting up with all features except Kmail. A re-boot brought it back. However I am now experiencing one of several imap accounts not syncing. This is a recurring issue after most updates. The only way to check for new email is to run akonadiconsole, stop the server, start the server, or just do a restart on the server.
In the past the imap account can be deleted and after ending Kontact and restarting Kontact the account can be added back. The drawback to this approach is that all filtering for that imap account is destroyed and must be rebuilt. Backups of filters have proved to be sketchy when they are recovered.
Email syncing will start but then another imap account will be come unstable or un-usable. There is no consistent way to predict which account will be the next victim.
This may be related to the filters issue; I have noticed that if emails are manually moved from say the incoming mail folder to a subfolder the syncing will discontinue. However running akonadictl fsck will bring it back, sometimes. Again this isn’t a consistent fix.
I am running all current KDE applications and Plasma.
Any suggestions on how to get imap accounts then to consistently sync?
I think I already mentioned it here in this thread somewhere:
It should help to just kill the akonadi resource process (akonadi_imap_resource_X) that got stuck. It will be restarted automatically.
Other than that, to really get imap accounts syncing consistently you (or somebody else) would need to debug the problem and fix it…
As it happens quite randomly, this is not so easy though.
PS: I have 3 IMAP accounts here, and always the same one gets stuck.
It seems to happen if the connection to the server is lost while synchronizing.
In my case, apparently that particular server aborts if the sync takes too long. Reducing the number of mails in each IMAP folder might help there, but I haven’t bothered to do that yet.
Following this set of instructions has worked each time for me through multiple itterations of Akonadi “improvements”.
You must run Akonadiconsole in a user terminal.
go to the tab DB Console.
The search criteria should be in the lower portion of the window. If not add it just as Paul says below.
Then go to the Browser tab.
Right click on the offending email account and choose “Clear Akonadi Cache”
If you are not sure which email account is the offending account just clear the Akonadi Cache on all of them. I do not see that there is a way to clear Akonadi Cache on all accounts at one time.
Paul Eggleton 2015-02-24 14:03:58 UTC
I have at least figured out how to fix the database in order to get directories syncing again using the Akonadi Console. (Disclaimer: this worked for me, may not work for you, you might lose data if you aren’t careful, etc.)
First I searched to find the duplicate keys using the “DB Console” tab with the following query:
SELECT pimitemtable.*, collectiontable.name FROM pimitemtable
INNER JOIN pimitemtable dup ON pimitemtable.id != dup.id and pimitemtable.remoteId = dup.remoteId and pimitemtable.collectionId = dup.collectionId
INNER JOIN collectiontable ON pimitemtable.collectionId = collectiontable.id
ORDER by pimitemtable.remoteId
Then I looked for the items specifically in the folders that I knew were failing to sync with the “Multiple merge candidates, aborting” error, then used the Id to track down one of the duplicate items in the “Browser” tab and then deleted it there from the context menu. (There are still others with duplicate ids, but I have not deleted those since they don’t appear to be causing any problems.)
I then restarted the akonadi server, and then reloaded the folder in KMail and voila, the folder now synchronises successfully.
