KAlarm merge requestshttps://invent.kde.org/pim/kalarm/-/merge_requests2023-10-28T22:41:12Zhttps://invent.kde.org/pim/kalarm/-/merge_requests/39Port to new KNotifications action API2023-10-28T22:41:12ZDavid JarviePort to new KNotifications action APIUpdate merge request https://invent.kde.org/pim/kalarm/-/merge_requests/34 to target master branch (original branch kf6 has been removed)Update merge request https://invent.kde.org/pim/kalarm/-/merge_requests/34 to target master branch (original branch kf6 has been removed)David JarvieDavid Jarviehttps://invent.kde.org/pim/kalarm/-/merge_requests/25Clean up window system code2023-10-16T15:15:53ZNicolas FellaClean up window system codehttps://invent.kde.org/pim/kalarm/-/merge_requests/15Fix crash in FileResourceConfigManager when doing removeResource2022-07-20T21:38:21ZJiří PalečekFix crash in FileResourceConfigManager when doing removeResourceHello
this merge request seeks to fix a crash that I encountered when deleting an old calendar file from KAlarm. Here is [the backtrace and the result of valgrind pertaining to this crash](/uploads/bb11994b71b3abba931881329ff3f7cd/kalar...Hello
this merge request seeks to fix a crash that I encountered when deleting an old calendar file from KAlarm. Here is [the backtrace and the result of valgrind pertaining to this crash](/uploads/bb11994b71b3abba931881329ff3f7cd/kalarm.fileresourceconfigmanager.valgrind.txt).
As you can see, it is a use after free when running `ResourceSelector::removeResource()`. It deletes an instance of `FileResourceSettings` and then uses it.
The problematic code is here:
```
Resource resource(createResource(settings));
manager->mResources[settings->id()] = ResourceData(resource, settings);
```
where the first call creates the resource from `settings.data()` in `FileResourceManage::createResource`. This `Resource` is then stored in the global `Resources` instance, and holds a pointer to `settings`. Another pointer to `settings` is held in `manager->mResources`. But only one is managed by a `QSharedPointer` which means that on removal, if the first one to go is the managed one, the second one will be dangling and (in this case) used after free. This merge request fixes it by using the shared pointer throughout.
As an aside, I looked at other suspicious usages of `data()` and found only one. The second commit removes that as well in favor of normal shared pointer usage.https://invent.kde.org/pim/kalarm/-/merge_requests/17Update org.kde.kalarm.appdata.xml - include older versions to make the releas...2022-07-18T23:10:18ZJustin ZobelUpdate org.kde.kalarm.appdata.xml - include older versions to make the release version uniquehttps://invent.kde.org/pim/kalarm/-/merge_requests/5Remove icons that are part of upstream oxygen2022-04-17T15:16:41ZNicolas FellaRemove icons that are part of upstream oxygenhttps://invent.kde.org/pim/kalarm/-/merge_requests/10Remove redundnant QFile object2022-02-09T17:09:41ZOleg SolovyovRemove redundnant QFile objectfnew.isOpen() is never called -> fnew.isWritable() will always return falsefnew.isOpen() is never called -> fnew.isWritable() will always return false