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. However if another virtual machine were causing issues with PulseAudio then that shouldn't cause memory expansion/leaking in the Mumble client binary (AFAIK). >> Due to recent security bugs in Mumble I'm going to be preparing a version of >> Mumble 1.3 with Qt4 (targeted for Stretch) -- so there will be an >> opportunity to >> test that to see if it shows the same memory leak. > > I can also test if reverting to a previous version of Mumble helps; I'm > not sure which are the security issues but in my case I trust the server > so there might be no problem using an older version for testing. The two recent security issues relate to mumble-server specifically, not the client. One security issue has been resolved, another is described in Debian bug #919249 and on this Debian Secuirty page for CVE-2018-20743: https://security-tracker.debian.org/tracker/CVE-2018-20743 >> […] >> >> I don't personally know of a "good" way to debug memory leaks. As far as I >> know >> this involves running the target program via a debugger like GDB and figuring >> out how to watch memory allocations and frees. Unfortunately I don't have >> any >> experience with doing that [successfully] yet. > > Valgrind's memcheck is the best I know. I'll try to see if I can run > Mumble in it and find out what I can from there -- although it often is > a pain starting from nothing, as many toolkits and apps have gazillions > of innocent leaks cluttering the results. *headsmack* I keep forgetting about Valgrind. I can try playing with that too, assuming I can replicate the memory leak. > Thanks for the input, and I'll get back here with any data I can gather > on this. *nod* Thank you very much for your help. -- Chris -- Chris Knadle chris.kna...@coredump.us
