Le 08/02/2019 à 16:54, Chris Knadle a écrit : > Colomban Wendling: >> Le 07/02/2019 à 16:56, Chris Knadle a écrit : >>> […] >>> >>> Just to mention: this isn't the first report of "memory leak" on Mumble -- >>> see >>> Debian bug #683827. >>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=683827 >>> >>> I wasn't able to reproduce #683827 on newer versions of Mumble 1.2.x but >>> wasn't >>> sure what the underlying cause/issue was there, or what version of Mumble >>> may >>> have fixed that bug. >> >> The links you have there are interesting; for example >> https://github.com/mumble-voip/mumble/issues/1074#issuecomment-203199996 >> suggests that it might be due to echo canceller and other apps "messing" >> with PulseAudio. I do have echo canceller enabled (that I should >> actually be able to disable as I'm using push-to-talk with a headset), >> and am running at least one virtual machine which could be doing >> something with PulseAudio. >> >> I'll try and do some tests next chance I get (probably next week). > > *nod* Okay. Yeah the echo canceler would be part of the Mumble binary, so if > the canceler is misbehaving memory-wise then that would make sense.
I tried without the echo canceller and it's behaving reasonably so far, after 5 hours: it's using 109M resident memory, and peaked at 123M. So it seems it's indeed the echo canceller that's leaking a lot. > However if > another virtual machine were causing issues with PulseAudio then that > shouldn't > cause memory expansion/leaking in the Mumble client binary (AFAIK). IIUC from the report I linked, some software alter the input sinks in a way that confused the echo canceller. It'd say it's still a bug on the canceller part, but it might be triggered only on some conditions that don't normally happen, but that some software doing their own audio input trigger -- not quite sure. Regards, Colomban
