Today, I suddenly saw Korgac eat 800 mb of ram. I killed it and started it again. Within 20 seconds it was at 800 mb of ram usage again. Killed again, started again, went to 800 mb. I asked on the IRC channel how to debug this and was told to run valgrind and add the output here. So I do... I rebooted and at this very moment, Korgac is eating 591 mb of ram (not with valgrind) so the issue is still there. Hope you can find and fix it... Again, it happens real quick - I logged in less than 3 minutes ago so this isn't a slow memleak. I'd be happy to help debug it further... I made this a grave bug as, while I have 8 gb of ram here, this would make many systems unusable. Reproducible: Always Steps to Reproduce: 1. reboot 2. look at the memory usage of korgac 3.
Created attachment 78258 [details] massif.out output first run
Created attachment 78259 [details] massif.out second run I'd be happy to run valgrind more often...
Do you have any alarms of type "email" ?
Hi Sergio, Where can I check my alarms? I don't really use KOrganizer, but it has calendars from the KDE community (KDE sprints) and openSUSE (the openSUSE calendar). They probably have alarms, not sure - I never get alarms or messages from KOrganizer...
qdbus org.kde.korgac /ac dumpAlarms (no idea what /ac stands for, but I have that)
Does korganizer eat memory too, or just korgac ?
sergio, perhaps this one is fixed now? jos, can you try with a very recent version? sergio has done a lot of work to reduce memory usage.
Reproduced on kdepim-4.11.3-1.fc19.x86_64. The korgac process starts using ~90MiB (which seems pretty much to me for an event notifier) and then it starts growing in the memory. It grows in steps (420->500 happened just now with small pause on 480) and then it keeps the size for some time. (5 mins later: korgac just grew 500->580, small pause at 560)
Created attachment 83639 [details] end of the strace log from the growing period
after another 4-5mins, korgac grew 480->560 with small pause at 540
(In reply to comment #10) > after another 4-5mins, korgac grew 480->560 with small pause at 540 Can you get a massif report ?
Sergio Martins: unfortunatelly not. After reinstalling the kdepim rpm with the same version, the issue perished (mem consumption is stable around 120MiB which is IMO pretty high, but it's not growing anymore).
(In reply to comment #12) > Sergio Martins: unfortunatelly not. After reinstalling the kdepim rpm with > the same version, the issue perished (mem consumption is stable around > 120MiB which is IMO pretty high, but it's not growing anymore). Then closing as cantreproduce.. reopen if you can reproduce it again and I'll help you debug the problem.
FYI - can't reproduce this anymore, but qdbus org.kde.korgac /ac dumpAlarms gives no alarms atm. Memory usage is 27 mb and staying there... /J
(In reply to comment #13) > (In reply to comment #12) > > Sergio Martins: unfortunatelly not. After reinstalling the kdepim rpm with > > the same version, the issue perished (mem consumption is stable around > > 120MiB which is IMO pretty high, but it's not growing anymore). > > Then closing as cantreproduce.. reopen if you can reproduce it again and > I'll help you debug the problem. Please, reopen and send me instructions on getting the massif report. It's happenning again. Same pattern - RSS still for 5 min, then grows by 60+20MB.
From strace it seems that korgac touches (stat) /etc/localtime and /dev/urandom repeatedly (dunno if this information us usable or not, it's just the first obvious thing I'm seeing in the logs).
(In reply to comment #15) > (In reply to comment #13) > > (In reply to comment #12) > > > Sergio Martins: unfortunatelly not. After reinstalling the kdepim rpm with > > > the same version, the issue perished (mem consumption is stable around > > > 120MiB which is IMO pretty high, but it's not growing anymore). > > > > Then closing as cantreproduce.. reopen if you can reproduce it again and > > I'll help you debug the problem. > > Please, reopen and send me instructions on getting the massif report. It's > happenning again. Same pattern - RSS still for 5 min, then grows by 60+20MB. Can you reproduce getting it to 800MB ?
If it doesn't magically disappear, then yes, I suppose. I'll post you tomorrow (it happens on my work computer). However, I ran it under valgrind / massif so I can upload the report tomorrow, too.
Here it is: Every 1.0s: ps -eo pid,comm,rss | grep korgac Thu Nov 28 09:53:00 2013 14571 korgac 833548
Every 1.0s: ps -eo pid,comm,rss | grep korgac Thu Nov 28 09:53:00 2013 14571 korgac 833548
Every 1.0s: ps -eo pid,comm,rss | grep korgac Thu Nov 28 09:59:19 2013 14571 korgac 913812
Created attachment 83806 [details] massif log (not sure if the issue was actually reproduced under massif)
Every 1.0s: ps -eo pid,comm,rss | grep korgac Thu Nov 28 10:17:41 2013 14571 korgac 1233868
Every 1.0s: ps -eo pid,comm,rss | grep korgac Thu Nov 28 10:59:01 2013 14571 korgac 1860312 that fast it is..
Martin, can you open akonadiconsole, and check your resource type ? Click on it, in the first tab, then bellow you'll see something like: akonadi_kcal_resource or akonadi_ical_resource, tell me which one it is.
Korgac was using >100MB of memory and lots of CPU when I imported about 10 ical files from Google calendar with ical resources. Akonadi (akonadiserver, mysql, ical resources) went out of control and used lots of CPU and disk IO for several hours, one ical resource was using > 500 MB of memory, and after that korgac memory usage stabilized. After restarting it, it uses ~ 25MB of memory according to System Activity (Ctrl-Esc), which is roughly what one would expect. This is on KDE 4.11.3, openSUSE 12.3.
Sergio, I suspect that my issue is caused by the patch from https://bugs.kde.org/show_bug.cgi?id=284884. It's somehow weird, I observed situation when kontact was growing and korgac not, but usually it's korgac and the resource is akonadi_davgroupware_resource (everything points that way - few comments above I described how it leaks 80MB every 5min: I have the DAV resource set 5m checking interval and difference in memory utilization w/o DAV resource and with it is ~80MB). Common thing is that both (kontact and korganizer) are opening and closing /dev/urandom like crazy when leaking.
Now that you mention /dev/urandom, I recall that when I was importing the ical files, a message about failure to validate the certificates of Google.com appeared once, while the details in the same window showed that the certificate was valid. Could there be some race with SSL checks?
I think this bug can be closed again. My issue is indeed caused by the patch; we can furher discuss it in the new review for the patch: https://git.reviewboard.kde.org/r/114357/
Git commit f5793f3ca80aeda4275d7f4a9605051f6593caa7 by Christian Mollekopf. Committed on 20/03/2014 at 19:06. Pushed by cmollekopf into branch 'KDE/4.13'. Skip virtual collections to avoid accidentaly loading a search collection. Otherwise it can happen that huge amount of mails are loaded into memory just to be discarded (2gb korgac anyone?). I noticed this in korgac, korganizer, and kmail when trying to open invitations. The reason were 60000 email in my Last Search folder. M +1 -1 akonadi/calendar/incidencefetchjob_p.cpp http://commits.kde.org/kdepimlibs/f5793f3ca80aeda4275d7f4a9605051f6593caa7
Git commit b5b8c4e9bb7665042cceba3900d94deec78dd0a8 by Christian Mollekopf. Committed on 20/03/2014 at 21:31. Pushed by cmollekopf into branch 'KDE/4.13'. Skip virtual collections to avoid accidentaly loading a search collection. Otherwise it can happen that huge amount of mails are loaded into memory just to be discarded (2gb korgac anyone?). I noticed this in korgac, korganizer, and kmail when trying to open invitations. The reason were 60000 email in my Last Search folder. This is the same fix as in kdepimlibs. M +1 -1 calendarsupport/next/incidencefetchjob.cpp http://commits.kde.org/kdepim/b5b8c4e9bb7665042cceba3900d94deec78dd0a8