Colomban Wendling: > Package: mumble > Version: 1.3.0~git20190125.440b173+dfsg-1 > Severity: important > > Dear Maintainer, > > I use Mumble daily as a remote work team communication channel, so it's pretty > much open non-stop for one day at a time.
Understood. I typically also leave the Mumble client open for long periods of time, but have not tried doing this with Mumble 1.3 yet. When possible I'll try to replicate this bug to see if I see the same behavior. > Since a few days, maybe a week, Mumble's memory usage is steadily growing to > crzay levels: right now, `top` report it's using 25% of my 12Go of memory > (resident memory shows 3g). This situation forces me to restart the client > every now and then, unfortunately at least a few times a day -- and > obviously is also a problem for overall use of resources. > I wouldn't say it started right away with the new Qt5 Mumble, but it could > have, I'm not completely sure. > > It wasn't always like that, and used to work fine. 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. 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 cannot really provide credentials for the server, but I can do tests if > need be. There is no issue I can see on Mumble's stdout/stderr: > > <D>2019-02-07 10:49:42.966 libopus 1.3 from libopus.so.0 > <W>2019-02-07 10:49:42.967 CELT bitstream 8000000b from > /usr/lib/mumble/libcelt0.so.0.7.0 > <W>2019-02-07 10:49:42.970 Theme: "Mumble" > <W>2019-02-07 10:49:42.970 Style: "Lite" > <W>2019-02-07 10:49:42.970 --> qss: ":themes/Mumble/Lite.qss" > <W>2019-02-07 10:49:42.971 Locale is "fr_FR" (System: "fr_FR") > <W>2019-02-07 10:49:43.215 Database SQLite: "3.26.0" > <W>2019-02-07 10:49:43.219 Overlay: Listening on > "/run/user/1000/MumbleOverlayPipe" > <W>2019-02-07 10:49:43.252 Updating application palette > <W>2019-02-07 10:49:43.291 GlobalShortcutX: Using XI2 2.3 > <W>2019-02-07 10:49:44.697 AudioInput: Opus encoder set for VOIP > <W>2019-02-07 10:49:44.697 AudioInput: 23000 bits/s, 48000 hz, 480 sample > <W>2019-02-07 10:49:44.697 PulseAudio: Starting input > alsa_input.pci-0000_00_1b.0.analog-stereo > <W>2019-02-07 10:49:44.697 PulseAudio: Starting echo: > alsa_output.pci-0000_00_1b.0.analog-stereo.monitor > <W>2019-02-07 10:49:44.697 PulseAudio: Starting output: > alsa_output.pci-0000_00_1b.0.analog-stereo > <W>2019-02-07 10:49:44.699 AudioOutput: Initialized 2 channel 48000 hz mixer > <W>2019-02-07 10:49:44.699 AudioInput: Initialized mixer for 1 channel 44100 > hz mic and 0 channel 48000 hz echo > warning: The VAD has been replaced by a hack pending a complete rewrite > <W>2019-02-07 10:49:44.726 AudioInput: Initialized mixer for 1 channel 44100 > hz mic and 2 channel 48000 hz echo > warning: The VAD has been replaced by a hack pending a complete rewrite > <W>2019-02-07 10:49:44.736 AudioInput: ECHO CANCELLER ACTIVE > <W>2019-02-07 10:49:44.847 Database SQLite: "3.26.0" > <W>2019-02-07 10:49:44.848 OpenSSL Support: 1 (OpenSSL 1.1.1a 20 Nov 2018) > <W>2019-02-07 10:49:45.277 ServerHandler: TLS cipher preference is > "TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:AES256-SHA:AES128-SHA" > > Regards, > Colomban 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. -- Chris -- Chris Knadle [email protected]
