search

ElvishArtisan / rivendell

A full-featured radio automation system targeted for use in professional broadcast and media environments
197 stars 63 forks source link

Possible Memory Leak: caed. #934

Open alexolivan opened 6 months ago

alexolivan commented 6 months ago

A long time suspicion, masked by the more prominent (in the event of extensive recording) known leak from ripcd, I dare to finaly state that caed has, possibly, a kind of similar issue. While running ripcd under valgrind to try to get some clue on its memory leak, the leak itself is contained, allowing the system to keep running much longer without a rivendell restart. Munin graph on the caed process pointed out that the process, does not stop to keep claiming more and more RAM. After almost two weeks from last restart, caed, which usually starts with around 350 Mb of memory footprint, had reached the 1GB memory mark, and kept climbing.

Thankfully, all the other processes of the rivendell suite do behave healthy, with their memory usage graphs averaging a nice flat shape.

Now I'm running both ripcd and caed under valgrind, trying to get further info.

Cheers.

ElvishArtisan commented 6 months ago

Thanks for staying on this Alejandro. This is on a JACK-based setup, correct?

alexolivan commented 6 months ago

Hi Fred.

Yes. Same VM testbed, everything is 'just software' (although I keep building Rivendell with HPI deps enabled. Disabling them didn't made any difference anyways).

I would add that, while I found that valgrind manages to contain ripcd leak while watching it, it fails to do the same with caed, so something of different kind may be happening there... I have but not dug further on this (I lack the knowledge to grasp whats going on on those valgrind logs) just get it documented, to eventually mess with it on the future.

Cheers.

ElvishArtisan commented 6 months ago

Are you still running that on Debian Bookworm? I'd like to try to replicate your environment as precisely as possible here.

alexolivan commented 6 months ago

Nope... it is Debian Bullseye. Although I nightly build both bookworm and bullseye, I didn't dist-upgrade the VM, since there appeared to be initially some issues with ASI drivers and 6.X Kernels... so I though that staying on Bullseye's 5.X for a while.

This christmas holydays would be a nice opportunity to give a try to dist-upgrade and, if successful, re-check how does these leaks behave on new environment... maybe they simply disappear once on a Bookworm environment.