Bug 410179 - PIM events in Plasma calendar causes OOM killer
Summary: PIM events in Plasma calendar causes OOM killer
Status: RESOLVED FIXED
Alias: None
Product: Akonadi
Classification: Frameworks and Libraries
Component: general (show other bugs)
Version: unspecified
Platform: Arch Linux Linux
: NOR crash
Target Milestone: ---
Assignee: kdepim bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-07-25 08:03 UTC by Martin Ottmar
Modified: 2022-10-11 06:39 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
plasmashell console output (50.43 KB, text/plain)
2019-07-26 06:57 UTC, Martin Ottmar
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Martin Ottmar 2019-07-25 08:03:15 UTC
SUMMARY
Since plasma 5.16.3 there is a problem with plasmashell memory consumption. It takes about 2.1GB of RAM just after start. Remember me, was it less than 200MB before? :-o

I have nothing special. Two panels. The basic (hiding) panel contains few icons, temperature monitor (CPU and GPU temperature monitoring), standard weather widget and kdeconnect. The additional hiding pannel contains network monitor only.
There are not any other widgets or icons on the destop (just black background), I don't use features like activities or semantic desktop (or anyhow else you call it). KWIN compositing is turned on, but only few. I'm using this same configuration for years.

The interesting is that if I don't start my usual applications and the OOM killer keeps the plasmashell running, the memory consumption gets back to normal (about 150MB) after some while (about 10 minutes). It is not preceded by any special CPU activity

I have laptop with 8GB of memory but 3GB are preserved for tmpfs (ramdisks in order to spare writting cycles for SSD). The swap memory is completely turned off.
 
Private memory
2011600 KB	[heap]
5320 KB	/memfd:JSGCHeap:/usr/lib/libQt5Qml.so.5 (deleted)
4396 KB	/usr/lib/libLLVM-8.so
2112 KB	/usr/lib/libtelepathy-qt5.so.0.0.9.7
1768 KB	~/.cache/plasma_theme_oxygen_v5.60.0.kcache

Shared memory
33644 KB /usr/lib/libLLVM-8.so
6128 KB	/usr/lib/dri/radeonsi_dri.so
5144 KB	/usr/lib/libQt5Gui.so.5.13.0
4316 KB	/usr/lib/libQt5Core.so.5.13.0
3884 KB	/usr/lib/libQt5Qml.so.5.13.0

Totals
Pixmap	34604 KB	(Might be stored in the graphics card's memory)
Private	2056140 KB	(= 25624 KB clean + 2030516 KB dirty)
Shared	133268 KB	(= 133176 KB clean + 92 KB dirty)
Rss	2189408 KB	(= Private + Shared)
Pss	2081083 KB	(= Private + Shared/Number of Processes)
Swap	0 KB


STEPS TO REPRODUCE
1. Just start KDE and wait until plasma shell is fully loaded


OBSERVED RESULT
Plasmashell is killed by OOM killer when running my applications as usual. If not, the memory consumption gets back to normal after cca 10 minutes of running


EXPECTED RESULT
Plasmashell starts and keeps running consuming much less memory (cca. 150MB of RAM)


SOFTWARE/OS VERSIONS
Linux/KDE Plasma: Archlinux
KDE Plasma Version: 5.16.3
KDE Frameworks Version: 5.60.0
Qt Version: 5.13.0

ADDITIONAL INFORMATION
Comment 1 David Edmundson 2019-07-25 23:04:36 UTC
Please can you run QSG_INFO=1 plasmashell and paste the output.

Please move your ~/.config/plasma-org.kde.plasma.desktop-appletsrc and see if that makes a difference.

Finally can you run kcmshell5 qtquicksettings and select the software renderer and see if that makes a difference.
Comment 2 Martin Ottmar 2019-07-26 06:57:28 UTC
Created attachment 121737 [details]
plasmashell console output
Comment 3 Martin Ottmar 2019-07-26 07:36:18 UTC
(With the current configuration): Running with the software renderer doesn't make any difference. Even with compositing completely turned off.

After the "configuration reset", plasmashell starts immediately with the "usual" size in memory, but... Today I've noticed that just after boot, the plasmashell was running with the "usual" portion of memory. But, it was killed by OOM killer after 22 minutes of uptime. If I remember well, the progress was the same yesterday in the morning. The first killing occurred after some amount of time, but each (working) day, I'm using my system exactly the same way.
So, I'm going to try to configure plasma again, as it was before the configuration reset and to watch its behaviour carefully. For now, thanks for Your interest and I'm sorry for my bad English.

BTW: what does the "Tokenizer Warning: 8Bit character" message mean? I mean, how to distinguish, from where it comes from? I've noticed it before within restarting akonadi (when I was fighting with akonadi problems). I'm using UTF-8 within the whole system
Comment 4 Martin Ottmar 2019-07-27 08:44:49 UTC
It seems that the problem won't appear until I enable "PIM events plugin" in settings of digital clock applet. When I enable "PIM events plugin" option, there are missing calendars to choose at all in the side "tab", but at the moment, akonadiserver, mysql and akonadi_imap_resource_3(?!) start to exhaust CPU for a lot of minutes. And RAM allocated for plasmashell starts to grow slowly (cca 200kB per second?). And then, let's say, after cca 10minutes (probably just when akonadi_indexing_agent starts) the consumed memory skyrokets up to 2GB... If there is enough of free memory and OOM killer leaves plasmashell running, then CALDAV calendar events finally appear in the digital clock calendar, and akonadi stops draining CPU. This akonadi behaviour is new too.
Comment 5 David Edmundson 2019-07-28 17:58:23 UTC
Ok, please file a bug with this information to akonadi.

I don't think we can do much from the plasma side.
Comment 6 Bug Janitor Service 2019-08-12 04:33:10 UTC
Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least
15 days. Please provide the requested information as soon as
possible and set the bug status as REPORTED. Due to regular bug
tracker maintenance, if the bug is still in NEEDSINFO status with
no change in 30 days the bug will be closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

If you have already provided the requested information, please
mark the bug as REPORTED so that the KDE team knows that the bug is
ready to be confirmed.

Thank you for helping us make KDE software even better for everyone!
Comment 7 Christoph Feck 2019-08-14 02:14:14 UTC
Moving to Akonadi as suggested in comment 5.
Comment 8 Justin Zobel 2022-09-24 09:52:33 UTC
Thank you for reporting this crash in KDE software. As it has been a while since this issue was reported, can we please ask you to see if you can reproduce the crash with a recent software version?

If you can reproduce the issue, please change the status to "CONFIRMED" when replying. Thank you!
Comment 9 Martin Ottmar 2022-09-26 08:04:26 UTC
Oh, I'm sorry. I've tried to enable the digital clock PIM plugin few weeks ago, and it didn't crash. PIM started immediately, with working kalendar and containing valid PIM informations. There is not any CPU or (noticeable) memory impact on plasmashell. There is nice new feature like dots as events by each day. At least dots by the first visible day (of each month page) have invalid color, but damn it! Digital clock caPIM events work again within daily using! But I don't know, when it was fixed. The last unsuccessful try before, it was probably last year.
I think, this ticket should be closed.

Plasma: 5.25.5
Frameworks: 5.98.0
Comment 10 Bug Janitor Service 2022-10-11 04:52:44 UTC
Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least
15 days. Please provide the requested information as soon as
possible and set the bug status as REPORTED. Due to regular bug
tracker maintenance, if the bug is still in NEEDSINFO status with
no change in 30 days the bug will be closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

If you have already provided the requested information, please
mark the bug as REPORTED so that the KDE team knows that the bug is
ready to be confirmed.

Thank you for helping us make KDE software even better for everyone!