Bug 375395 - Plasma consumes all memory when showing calendar popup
Summary: Plasma consumes all memory when showing calendar popup
Status: RESOLVED DUPLICATE of bug 377160
Alias: None
Product: plasmashell
Classification: Plasma
Component: Calendar (show other bugs)
Version: 5.8.5
Platform: openSUSE Linux
: NOR major
Target Milestone: 1.0
Assignee: Plasma Bugs List
URL:
Keywords:
: 375458 (view as bug list)
Depends on:
Blocks:
 
Reported: 2017-01-22 00:43 UTC by Jure Repinc
Modified: 2018-01-03 09:52 UTC (History)
7 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments
complete valgrind log (1.17 MB, application/x-xz)
2017-01-22 00:43 UTC, Jure Repinc
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jure Repinc 2017-01-22 00:43:56 UTC
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
Comment 1 Marco Martin 2017-01-26 16:22:19 UTC
*** Bug 375458 has been marked as a duplicate of this bug. ***
Comment 2 CnZhx 2017-02-04 10:36:14 UTC
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?
Comment 3 info 2017-04-13 20:50:53 UTC
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.
Comment 4 Bernhard Scheirle 2017-06-06 05:10:25 UTC
I can reproduce this with KDE Neon 5.10.
I have tasks in my calendars and some of them are CalDav calendars.
Comment 5 Alexander Mentyu 2017-12-06 11:55:51 UTC
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
Comment 6 Jure Repinc 2017-12-16 20:48:53 UTC
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.
Comment 7 Kai Uwe Broulik 2018-01-03 09:52:17 UTC

*** This bug has been marked as a duplicate of bug 377160 ***