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). > 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. > […] > > 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. Thanks for the input, and I'll get back here with any data I can gather on this. Regards, Colomban
