[SailfishDevel] memory leak?

[E.S. Rosenberg]

Hi David,
I have been using htop to monitor what is going on before and after closing.
In the past I've used valgrind for C++ projects (openlighting) but this is
python/QML with no compiled code (from my side) at all to the best of my
understanding valgrind can't help me with this, but I may be wrong.

Memory usage of the newer version of gPodder is definitely higher (it loads
a large amount of images) but it's also not released with closing gPodder
(which does not background) so I suspect there is some bad synergy
happening by a memory leak in system libraries being exasperated by gPodder.
I downgraded on my phone and I could push memory usage up by just switching
between lots of different pages and it seems pages don't get cleared from
memory when not in use, though memory usage did drop a bit when I locked
the screen.
(By opening all podcast information pages which include logos and all
episode listings one after the other I managed to enlarge the total memory
footprint [VIRT] from ~500M to 1200M after screen lock it dropped back down
to ~850M, resident memory usage [RES] was doubled by this and never dropped
back down)
In the newer version the episode listings are much heavier because each
episode comes with a picture.

Thanks,
Eli

Op ma 13 apr. 2020 om 17:03 schreef David Llewellyn-Jones <
david at flypig.co.uk>:

> On 13/04/2020 15:54, E.S. Rosenberg wrote:
> > Recently I've noticed my phone running out of memory more often.
> > I've update to 3.3.0.14 but I also released a newer version of gPodder
> > which may be guilty of this.
> > However closing gPodder does not release memory so I'm not really sure
> > if I should blame myself or that lipstick is after all leaking memory.
> > Also how does one optimize a qml/python apps memory usage? Neither is
> > managed to the best of my knowledge.
> > I may have time later to test the level of involvement of gPodder by
> > downgrading.
>
> Hi Eli,
>
> If the memory isn't released when gPodder's closed (assuming the app is
> definitely closed, and not just hidden), then it's highly unlikely to be
> gPodder draining your memory.
>
> A very simple way to check memory usage is just to take a look at the
> output of "top". The following will show everything running ordered by
> memory usage and keep it updated:
>
> top -o %MEM
>
> Or if you just want to track gPodder you could use something like this:
>
> top -o %MEM -p `pgrep sailfish-qml`
>
> I used sailfish-qml as the app name, since probably that's what gPodder
> will be called if it's QML/python-only, but you can change it to
> whatever you're interested in.
>
> Finally I was going to suggest to run it with valgrind, which gives a
> summary of memory leaks when you close the app and I've found useful in
> the past for C++ code. Unfortunately when I tried it on another QML-only
> app the results weren't very helpful at all. So this may not be a
> helpful route to go down.
>
> Nevertheless I uploaded an RPM to openrepos in case it's helpful in some
> other context:
>
> https://openrepos.net/content/flypig/valgrind
>
> David
> --
> Website: https://www.flypig.co.uk
> _______________________________________________
> SailfishOS.org Devel mailing list
> To unsubscribe, please send a mail to
> devel-unsubscribe at lists.sailfishos.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.sailfishos.org/pipermail/devel/attachments/20200413/01e61ca1/attachment.html>