After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 432886 - Memory leak when playing transcoded wav stream off of mt-daapd
Memory leak when playing transcoded wav stream off of mt-daapd
Status: RESOLVED DUPLICATE of bug 407057
Product: rhythmbox
Classification: Other
Component: DAAP
0.10.0
Other All
: Normal critical
: ---
Assigned To: RhythmBox Maintainers
RhythmBox Maintainers
Depends on:
Blocks:
 
 
Reported: 2007-04-24 08:58 UTC by Indriði Einarsson
Modified: 2007-04-24 09:12 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Valgrind log (40.22 KB, application/x-compressed-tar)
2007-04-24 08:59 UTC, Indriði Einarsson
Details

Description Indriði Einarsson 2007-04-24 08:58:19 UTC
Please describe the problem:
Am running rhythmbox 0.10.0 on ubuntu feisty fawn. 
Have mt-daapd (svn-1549) on Debian, which
transcodes .ogg files to a .wav stream on-the-fly, and serves them as such
(since some clients don't read ogg) This works fine with my roku soundbridge, as with rhythmbox (used to be an issue, but isn't any more, see bug 350276), but rhythmbox seems to leak memory in the process.

Right now, top claims the rhythmbox process is using 20% of my 1Gb (plus 2 Gb swap), ps -AF returns

[indridi@edelstoff][...indridi/leit] ps -AF | grep rhy
indridi 2014 1893 5 92178 227772 0 22:29 pts/4 00:01:58 rhythmbox

The leak seems to be related to the format of music being streamed from the md-daapd server. When streaming .ogg or .mp3 files directly, the memory usage stays stable (although the memory it has already eaten isn't returned), but when playing a stream which is transcoded in .wav format before streaming, the memory usage rises continuously, e.g. now, approx 5 minutes later than the previous ps -AF, it now returns

indridi 2014 1893 5 102601 276808 0 22:29 pts/4 00:02:02 rhythmbox
This process, if left alone, ends up eating all the memory on my system, the 1GB physical memory, and enough of the swap for the system to become totally unresponsive

Someone here might know if this is caused by rhythmbox, or maybe gstreamer.

Playing ogg (or mp3) files from mt-daapd without any transcoding works fine.

Steps to reproduce:
1. Serve music off of a mt-daapd server, use transcoding option, as is necessary for some clients
2. connect to the shared music with rhythmbox.
3. double click on a song, which the mt-daapd server will transcode on the fly and serve as a wav file


Actual results:
Rhythmbox plays the tune, but keeps reserving more and more memory.

Expected results:
Rhythmbox shouldn't eat up all my precious memory.

Does this happen every time?
yes.

Other information:
Have run rhythmbox using valgrind 

G_SLICE=always-malloc G_DEBUG=gc-friendly valgrind -v --tool=memcheck --leak-check=full --num-callers=40 --log-file=valgrind.log rhythmbox

 for around five minutes (the system is almost unusable - valgrind is heavy), during which I start rhythmbox, connect to a mt-daapd share, an play one song through and half of another, then I quit the program. During this time, the memory ps -AF claims rhythmbox uses rose continuously the whole time, a few Mb a minute.
Comment 1 Indriði Einarsson 2007-04-24 08:59:50 UTC
Created attachment 86907 [details]
Valgrind log

The valgrind log mentioned above.

Indriði Einarsson
Comment 2 James "Doc" Livingston 2007-04-24 09:12:15 UTC
This would be bug 407057, which has been fixed in gst-plugins-good from cvs. Hopefully there will be a new -good release sometime.

*** This bug has been marked as a duplicate of 407057 ***