| Summary: | Plasma consumes all memory when showing calendar popup | ||
|---|---|---|---|
| Product: | [Plasma] plasmashell | Reporter: | Jure Repinc <jlp> |
| Component: | Calendar | Assignee: | Plasma Bugs List <plasma-bugs> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | major | CC: | bernhard+kde, courthicks1, info, kde, notuxius, rdieter, zhx |
| Priority: | NOR | ||
| Version: | 5.8.5 | ||
| Target Milestone: | 1.0 | ||
| Platform: | openSUSE | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
| Attachments: | complete valgrind log | ||
*** Bug 375458 has been marked as a duplicate of this bug. *** I doubt this is because the bug of https://bugs.kde.org/show_bug.cgi?id=367541 Have you tried to deselect tasklist/to-do list within "Select Calendars" in "PIM Events Plugin" in "Digital Clock Settings" page to see if it makes any different? The widget works without problems when all Calendars are deselected in its settings. When I try to select one and press apply, the CPU goes to 100% until the kernel kills plasmashell due to its memory usage. Any of my calendars causes this behavior. My calendars are all CalDav-Calendars, if this is of interest. All of these calendars contain at least one TODO-Item. The native "Birthdays & Anniversaries" calendar works just fine. I can reproduce this with KDE Neon 5.10. I have tasks in my calendars and some of them are CalDav calendars. Can confirm, i described RAM consumption in my case in https://bugs.kde.org/show_bug.cgi?id=377160 Distribution: KDE neon Developer Edition - Stable Branches Plasma: 5.11.4 Frameworks: 5.41.0 Qt: 5.9.3 Kernel 4.10.0-40-generic Type: 64-bit Yeah looks like bug 377160 is the same bug. Thanks to the comments there I found a workaround: set the start date of all TODOs and the problem described here is gone for me too. Remove the start date and it is back. *** This bug has been marked as a duplicate of bug 377160 *** |
Created attachment 103578 [details] complete valgrind log I get this memory consumption bug ever since I created a TODO from within KMail. What happens now is this. I click the clock plasmoid in Plasma panel to show calendar popup and plasmashell process starts to consume a lot of memory very fast until it uses all of 32 GiB of memory and is eventually killed by OOM killer. I have run plasmashell via valgrind (valgrind --leak-check=full --track-origins=yes --show-leak-kinds=all -v plasmashell) and these reports appear to be related with this memory leak: ==5244== 1,073,741,824 bytes in 1 blocks are still reachable in loss record 65,127 of 65,128 ==5244== at 0x4C2BE3F: operator new[](unsigned long) (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==5244== by 0xA9E1B04: QHashData::rehash(int) (qhash.cpp:687) ==5244== by 0xC1EEE72F: willGrow (qhash.h:104) ==5244== by 0xC1EEE72F: insertMulti (qhash.h:777) ==5244== by 0xC1EEE72F: insert (qhash.h:1012) ==5244== by 0xC1EEE72F: EventDataVisitor::insertResult(CalendarEvents::EventData const&) (eventdatavisitor.cpp:179) ==5244== by 0xC1EEF3B2: EventDataVisitor::visit(QSharedPointer<KCalCore::Incidence> const&, CalendarEvents::EventData::EventType) (eventdatavisitor.cpp:157) ==5244== by 0xC1EEF777: EventDataVisitor::visit(QSharedPointer<KCalCore::Todo> const&) (eventdatavisitor.cpp:171) ==5244== by 0xC27D055F: KCalCore::Todo::accept(KCalCore::Visitor&, QSharedPointer<KCalCore::IncidenceBase> const&) (in /usr/lib64/libKF5CalendarCore.so.5.4.0) ==5244== by 0xC1EEF9BD: BaseEventDataVisitor::act(QVector<QSharedPointer<KCalCore::Todo> > const&) (eventdatavisitor.cpp:53) ==5244== by 0xC1EE946A: PimEventsPlugin::loadEventsForDateRange(QDate const&, QDate const&) (pimeventsplugin.cpp:66) ==5244== by 0xC1AC7C28: DaysModel::update() (daysmodel.cpp:105) ==5244== by 0xC1AC618F: Calendar::updateData() [clone .part.7] (calendar.cpp:300) ==5244== by 0xC1AC660C: updateData (calendar.cpp:96) ==5244== by 0xC1AC660C: Calendar::resetToToday() (calendar.cpp:95) ==5244== by 0xC1AD0414: Calendar::qt_static_metacall(QObject*, QMetaObject::Call, int, void**) (moc_calendar_LUV6MJZILS5OPX.cpp:237) ==5244== ==5244== 3,203,348,064 bytes in 100,104,627 blocks are still reachable in loss record 65,128 of 65,128 ==5244== at 0x4C2B0AF: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==5244== by 0xA9E15C8: QHashData::allocateNode(int) (qhash.cpp:501) ==5244== by 0xC1EEE799: createNode (qhash.h:548) ==5244== by 0xC1EEE799: insertMulti (qhash.h:781) ==5244== by 0xC1EEE799: insert (qhash.h:1012) ==5244== by 0xC1EEE799: EventDataVisitor::insertResult(CalendarEvents::EventData const&) (eventdatavisitor.cpp:179) ==5244== by 0xC1EEF3B2: EventDataVisitor::visit(QSharedPointer<KCalCore::Incidence> const&, CalendarEvents::EventData::EventType) (eventdatavisitor.cpp:157) ==5244== by 0xC1EEF777: EventDataVisitor::visit(QSharedPointer<KCalCore::Todo> const&) (eventdatavisitor.cpp:171) ==5244== by 0xC27D055F: KCalCore::Todo::accept(KCalCore::Visitor&, QSharedPointer<KCalCore::IncidenceBase> const&) (in /usr/lib64/libKF5CalendarCore.so.5.4.0) ==5244== by 0xC1EEF9BD: BaseEventDataVisitor::act(QVector<QSharedPointer<KCalCore::Todo> > const&) (eventdatavisitor.cpp:53) ==5244== by 0xC1EE946A: PimEventsPlugin::loadEventsForDateRange(QDate const&, QDate const&) (pimeventsplugin.cpp:66) ==5244== by 0xC1AC7C28: DaysModel::update() (daysmodel.cpp:105) ==5244== by 0xC1AC618F: Calendar::updateData() [clone .part.7] (calendar.cpp:300) ==5244== by 0xC1AC660C: updateData (calendar.cpp:96) ==5244== by 0xC1AC660C: Calendar::resetToToday() (calendar.cpp:95) ==5244== by 0xC1AD0414: Calendar::qt_static_metacall(QObject*, QMetaObject::Call, int, void**) (moc_calendar_LUV6MJZILS5OPX.cpp:237) Complete valgrind.log is attached