Probably a consequence of the const/non-const changes (detaching?)
Untested, but based on a crash report by Allen, pointing to
ETMCalendar::alarms() calling BlockAlarmsAttribute::isAlarmTypeBlocked
on line 579.
Interesting, shouldn't the attribute be owned by the Collection in d->mCollectionMap? The parentCollection should be just a shallow copy, so going out of scope should just decrease the ref counter in the shared instance, nothing more. This could point to some more fundamental problem... Could you try to turn this into some test case in Akonadi?
Bah, now I see it - the trivial fix is to just make parentCollection a const, then the call to parentCollection.attribute<>() will use the const overload and not cause a detach (or make blockedAttr a const pointer, that should do the trick as well.
This is a fairly common pattern, I wonder how many similar bugs we may have introduced by the const/non-const attribute access... :(
Well, it's a copy of that collection, and the recent const/non-const change makes us detach that copy.
The alternative fix is to make that parentCollection variable const, then it will work like before. But it still reads to me like we're pointing into something that went out of scope (although with the implicit sharing it won't be the case anymore).