[L2Ork-dev] rpi running out of memory on test

Albert Graef aggraef at gmail.com
Fri Jul 31 02:37:48 EDT 2020

Hi Jonathan,

If there's a memory leak then it has been with us for some time. Running

valgrind purr-data -noprefs -nostdpath -nogui -nrt -noaudio

on Arch x86_64 (valgrind-3.16.0.GIT), I'm getting pretty consistent results
for current master, 2.12.0, 2.11.0, and 2.10.1. That's how far back my
package cache goes, and still earlier versions I can't build here on Arch
any more because of gcc 10 woes. But looking at old build logs from 2.9.0,
it seems that we already had figures in the same ballpark back then.
Anyway, here are the "in use at exit" figures I got on the various versions:

2.10.1 (20200311-rev.501d8b2b): 234,182,724 bytes in 217,733 blocks
2.11.0 (20200528-rev.8bf9dbb5): 234,247,713 bytes in 217,768 blocks
2.12.0 (20200730-rev.ad08cbc3): 234,179,797 bytes in 217,666 blocks
2.13.0 (20200730-rev.90a37d5e): 234,212,342 bytes in 217,721 blocks

The last figure is for the current master. Yeah, those figures look a bit
excessive, but to produce those it just takes one rogue external that grabs
a lot of memory and doesn't release it on exit. Even if I just launch the
GUI without even opening a patch, valgrind already reports some 3 MB of
memory on exit, and some 47 MB of heap memory being used in total. Of
course, vanilla is much leaner, but then it also comes without any
externals and with a GUI from the 1990s.

So while we should look into this some time, I wouldn't worry about this
too much. If it wasn't for the raspbian_stretch runner failing quite a lot
lately, that is. What is the hardware being used there? Is upgrading to a
Pi4 an option?


On Fri, Jul 31, 2020 at 5:05 AM Jonathan Wilkes <jon.w.wilkes at gmail.com>

> Hi all,
> It appears the rpi is running out of memory on the externals-tests.pd:
> https://git.purrdata.net/jwilkes/purr-data/-/pipelines/2401
> Can someone confirm 260 megabytes in use at program exit? Even when
> loading all externals, that doesn't seem correct.
> Also suspicious-- that patch had already made its way through all the
> external tests. So it appears valgrind is catching the out-of-memory
> error when the patch is closing and/or when purr data is quitting.
> Any hints on this one?
> Best,
> Jonathan
> _______________________________________________
> L2Ork-dev mailing list
> L2Ork-dev at disis.music.vt.edu
> https://disis.music.vt.edu/listinfo/l2ork-dev

Dr. Albert Gr"af
Computer Music Research Group, JGU Mainz, Germany
Email: aggraef at gmail.com, web: https://agraef.github.io/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://disis.music.vt.edu/pipermail/l2ork-dev/attachments/20200731/c87cc605/attachment-0001.html>

More information about the L2Ork-dev mailing list