Probably a consequence of the const/non-const changes (detaching?)
Details
Details
Untested, but based on a crash report by Allen, pointing to
ETMCalendar::alarms() calling BlockAlarmsAttribute::isAlarmTypeBlocked
on line 579.
Diff Detail
Diff Detail
- Repository
- R170 Akonadi Calendar
- Branch
- Applications/19.04
- Lint
No Linters Available - Unit
No Unit Test Coverage - Build Status
Buildable 10195 Build 10213: arc lint + arc unit
Comment Actions
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... :(
Comment Actions
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).