https://bugs.kde.org/show_bug.cgi?id=410596
--- Comment #5 from Jiri Palecek <jpale...@web.de> --- Hello, thanks for your effort. Yes, there are duplicate items: $ grep ^UID ~/.kde/share/apps/kalarm/*.ics | sort -k 3 -t: /home/jirka/.kde/share/apps/kalarm/calendar.ics:UID:b355410c-07af-4ded-abf3-d887430000a1 /home/jirka/.kde/share/apps/kalarm/displaying.ics:UID:KAlarm-disp-1593075078.221 /home/jirka/.kde/share/apps/kalarm/expired.ics:UID:KAlarm-exp-959849771.278 /home/jirka/.kde/share/apps/kalarm/expired.ics:UID:KAlarm-exp-959849771.278 /home/jirka/.kde/share/apps/kalarm/expired.ics:UID:KAlarm-exp-981216950.140 /home/jirka/.kde/share/apps/kalarm/expired.ics:UID:KAlarm-exp-981216950.140 /home/jirka/.kde/share/apps/kalarm/calendar.ics:UID:KAlarm-1906626020.755 /home/jirka/.kde/share/apps/kalarm/calendar.ics:UID:KAlarm-727370443.645 /home/jirka/.kde/share/apps/kalarm/calendar.ics:UID:6e28d948-c6ba-4127-ac36-8a01b672de95 /home/jirka/.kde/share/apps/kalarm/calendar.ics:UID:9f3cd70a-9e1d-4d08-81ae-8dea00eaa34c (In reply to David Jarvie from comment #4) > The valgrind crash is in fact different from the original crash. The I don't think so; yes, the backtraces (their upper frames) are different, however, I think this isn't important. The immediate place of the crash is the same, and the reason - a dangling pointer - is the same in both traces. I discovered the dangling pointer also in gdb. My hypothesis is, that while the native run goes through the same dangling pointer dereference as the valgrind run, natively it goes through because the memory hasn't been overwritten yet. It just crashes later when the freed memory gets reused. > valgrind crash shows that multiple calendar status changes are being > received in AlarmCalendar, before the processing of the previous one has > completed. What you mean? I don't see any indication of that from valgrind, IMHO it just crashed inside the same removeKAEvents call that deleted the data. Given that, I looked at AlarmCalendar::removedKAevents and it really seems fishy. It haphazardly deletes some events, then it randomly removes the collection which might or might not contain the pointers to data which were deleted. It seems this could cause the crash I see. Anyway, I have prepared a patch that fixes this method, by only leaving valid pointers in mResourceMap. It makes the crash go away (although I got another crash under valgrind, accompanied by the message that connection to akonadi was lost, possibly because execution under valgrind was so slow). I will post the patch here, although I was planning to send it through phabricator. -- You are receiving this mail because: You are watching all bug changes.
