debugging akonadi_control

[Sandro Knauß]

Hey,

> [snip]
> The above rule moves incoming mail from kde-pim into a mail folder
> inbox/mailinglists/kde-pim.
> The name of that folder is not present in the configuration file. Only a
> folder number (101) is present.
> I'd be surprised if that is a stable number. kmail2rc contains folder
> numbers as well. The KConfig files have sections like '[Folder-142]'.

well the folder numbers are ids from the underlying database that Akonadi 
uses. Well if you have 140 folders you will have that many entries in the 
folder list, but the ordering is only hold in the database. So if you remove 
the database you loose the mapping id <-> folder. That's why we as devs do not 
recommend to remove the database at all. But users learnt this bad behaviour 
"oh an issue" let's remove the database as first solution. Also deleting the 
database makes it often impossible for us to investigate the issue...

But it is quite hard to find a proper unique identifier, that matches in all 
cases. 

>     ~/.local/share/akonadi

here the database / data lives 

>     ~/.config/akonadi

this is the configuration of akonadi
> 
> Akonadi is meant to be a cache so I figured I might just stop akonadi,
> remove ~/.local/share/akonadi and start akonadi to get it back in a sort
> of fresh state.

Great an issue that is persistent. So at least we now know that the issue 
comes from your data.

> I'll continue the debugging, but have to say it's a tough job.

welcome to our world :D

Did you used akonadiconsole already? 
Is it maybe the mail you want to look at that triggers the bug? 
As the issue is inside MessageViewer this is maybe triggered by one specific 
mail. Do you know at what mail it crashes? try to open it via akonadiconsole. 
And via kmail --view <path>
But this does not explain why akonadi_control stops. But maybe we see two 
issues.

hefee