Bug#341772: quodlibet: severe memory leak
Hi, On mar, jan 31, 2006, dann frazier wrote: > With fakesink, watching top w/ 1s samples, I see it use around 36M > before it exits. So I think its safe to say its leaking memory at > approximately the same rate. You might want to check with the new upstream I uploaded which has some mem leak fixes. It's gst-plugins0.8 and gstreamer0.8 0.8.12-1 Bye, -- Loïc Minier <[EMAIL PROTECTED]> Current Earth status: NOT DESTROYED
Bug#341772: quodlibet: severe memory leak
On Fri, 2005-12-02 at 23:32 -0600, Joe Wreschnig wrote: > Can you run (on one of the files you're trying to play) > $ gst-launch playbin uri=file:///...somefile.ext > And check its memory usage? Sure; but that alone didn't do much: [EMAIL PROTECTED]:~$ gst-launch playbin uri=file:///space/audio/ogg/Color_Bars/Making_Playthings/03-Color_Bars-Eliza.ogg RUNNING pipeline ... (gst-launch-0.8:31950): GStreamer-CRITICAL **: gst_object_ref: assertion `GST_IS_OBJECT (object)' failed (gst-launch-0.8:31950): GStreamer-CRITICAL **: gst_object_ref: assertion `GST_IS_OBJECT (object)' failed (gst-launch-0.8:31950): GStreamer-CRITICAL **: gst_bin_add: assertion `GST_IS_ELEMENT (element)' failed (gst-launch-0.8:31950): GStreamer-CRITICAL **: gst_element_link_pads_filtered: assertion `GST_IS_ELEMENT (dest)' failed Waiting for the state change... got the state change. (gst-launch-0.8:31950): GStreamer-CRITICAL **: gst_object_unref: assertion `GST_IS_OBJECT (object)' failed So I tweaked the command line until it started to play: [EMAIL PROTECTED]:~$ gst-launch playbin uri=file:///space/audio/ogg/Color_Bars/Making_Playthings/03-Color_Bars-Eliza.ogg ! vorbisdec ! audioconvert ! alsasink WARNING: erroneous pipeline: could not link playbin0 to vorbisdec0 Trying to run anyway. RUNNING pipeline ... This appears to be leaking memory at approximately the same rate. It was using ~104M by the time it finished playing this 3.9M ogg. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#341772: quodlibet: severe memory leak
reassign 341772 gstreamer0.8-plugins 0.8.11-2 thanks On Mon, 2005-12-05 at 11:52 -0700, dann frazier wrote: > [EMAIL PROTECTED]:~$ gst-launch playbin > uri=file:///space/audio/ogg/Color_Bars/Making_Playthings/03-Color_Bars-Eliza.ogg > ! vorbisdec ! audioconvert ! alsasink The vorbisdec/audioconvert is unnecessary; playbin should set that all up by itself. I guess whatever fallback my system has for when I don't provide a sink isn't present on yours (probably something gconf-related). > WARNING: erroneous pipeline: could not link playbin0 to vorbisdec0 > Trying to run anyway. > RUNNING pipeline ... > > This appears to be leaking memory at approximately the same rate. It > was using ~104M by the time it finished playing this 3.9M ogg. Okay. Then this is a more general GStreamer bug, and if it happens from such a simple use of playbin, there's not any way QL can work around it. Does it happen with all files, or just Oggs? Does it happen with any other sinks (esdsink, osssink)? -- Joe Wreschnig <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part
Bug#341772: quodlibet: severe memory leak
On Mon, 2005-12-05 at 15:37 -0600, Joe Wreschnig wrote: > reassign 341772 gstreamer0.8-plugins 0.8.11-2 > thanks > > On Mon, 2005-12-05 at 11:52 -0700, dann frazier wrote: > > [EMAIL PROTECTED]:~$ gst-launch playbin > > uri=file:///space/audio/ogg/Color_Bars/Making_Playthings/03-Color_Bars-Eliza.ogg > > ! vorbisdec ! audioconvert ! alsasink > > The vorbisdec/audioconvert is unnecessary; playbin should set that all > up by itself. I guess whatever fallback my system has for when I don't > provide a sink isn't present on yours (probably something > gconf-related). > > > WARNING: erroneous pipeline: could not link playbin0 to vorbisdec0 > > Trying to run anyway. > > RUNNING pipeline ... > > > > This appears to be leaking memory at approximately the same rate. It > > was using ~104M by the time it finished playing this 3.9M ogg. > > Okay. Then this is a more general GStreamer bug, and if it happens from > such a simple use of playbin, there's not any way QL can work around it. > > Does it happen with all files, or just Oggs? flacs and mp3s as well > Does it happen with any > other sinks (esdsink, osssink)? Also occurs w/ osssink. Here's the commands I used: [EMAIL PROTECTED]:~$ gst-launch filesrc location=/space/audio/mp3/Orange\ Glass/saturn_and_the_moon.mp3 ! mad ! alsasink [EMAIL PROTECTED]:~$ gst-launch filesrc location=/space/audio/flac/Tegan_And_Sara/If_It_Was_You/13-Tegan_And_Sara-Come_On_Kids_\(Bonus_Track\).flac ! flacdec ! osssink [EMAIL PROTECTED]:~$ gst-launch filesrc location=/space/audio/flac/Tegan_And_Sara/If_It_Was_You/13-Tegan_And_Sara-Come_On_Kids_\(Bonus_Track\).flac ! flacdec ! alsasink -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#341772: quodlibet: severe memory leak
Package: quodlibet Version: 0.15-3 Severity: important Once I hit play, a python process begins leaking memory on the order of about 1MB per second. My workstation starts swapping and becomes unusable until the oom-killer activates. I removed the -plugins & -ext packages to make sure they weren't at fault. Let me know what other information I can provide to assist in debug. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: ia64 Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.12-1-mckinley Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages quodlibet depends on: ii gstreamer0.8-mad 0.8.11-2 MAD MPEG audio decoder plugin for ii gstreamer0.8-oss [gstreamer0. 0.8.11-2 OSS plugin for GStreamer ii gstreamer0.8-vorbis 0.8.11-2 Vorbis plugin for GStreamer ii libgtk2.0-0 2.8.8-1The GTK+ graphical user interface ii python2.3.5-3An interactive high-level object-o ii python-gst0.8.2-1generic media-playing framework (P ii python-gtk2 2.6.3-2Python bindings for the GTK+ widge ii python-pymad 0.5.4-1Python wrapper to the MPEG Audio D ii python-pyvorbis 1.3-1 A Python interface to the Ogg Vorb ii python2.3-pymad [python-pymad 0.5.4-1Python wrapper to the MPEG Audio D Versions of packages quodlibet recommends: ii libgstreamer-gconf0.8-0 0.8.11-2 GConf support for GStreamer pn python-gnome2-extras (no description available) pn python2.3-gnome2 (no description available) pn quodlibet-ext (no description available) -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#341772: quodlibet: severe memory leak
On Fri, 2005-12-02 at 15:40 -0700, dann frazier wrote: > Package: quodlibet > Version: 0.15-3 > Severity: important > > Once I hit play, a python process begins leaking memory on the order of > about 1MB per second. My workstation starts swapping and becomes unusable > until the oom-killer activates. I removed the -plugins & -ext packages to > make > sure they weren't at fault. Let me know what other information I can provide > to assist in debug. Can you run (on one of the files you're trying to play) $ gst-launch playbin uri=file:///...somefile.ext And check its memory usage? -- Joe Wreschnig <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part
Bug#341772: quodlibet: severe memory leak
Hi, On Fri, Dec 02, 2005, dann frazier wrote: > Once I hit play, a python process begins leaking memory on the order of > about 1MB per second. My workstation starts swapping and becomes unusable > until the oom-killer activates. I removed the -plugins & -ext packages to > make > sure they weren't at fault. Let me know what other information I can provide > to assist in debug. Does it happen with ogg files only? Does it happen in the GStreamer 0.10 series? Cheers, -- Loïc Minier <[EMAIL PROTECTED]> Current Earth status: NOT DESTROYED
Bug#341772: quodlibet: severe memory leak
On Sun, 2006-01-08 at 10:47 +0100, Loïc Minier wrote: > Hi, hey Loïc, > On Fri, Dec 02, 2005, dann frazier wrote: > > Once I hit play, a python process begins leaking memory on the order of > > about 1MB per second. My workstation starts swapping and becomes unusable > > until the oom-killer activates. I removed the -plugins & -ext packages to > > make > > sure they weren't at fault. Let me know what other information I can > > provide > > to assist in debug. > > Does it happen with ogg files only? Also happens with flacs & mp3s - details are included in the bug report, search for flac. > Does it happen in the GStreamer > 0.10 series? Nope, seems fine in 0.10. I also doublechecked that I can still reproduce with 0.8.
Bug#341772: quodlibet: severe memory leak
Hi Dann, On Mon, Jan 09, 2006, dann frazier wrote: > Also happens with flacs & mp3s - details are included in the bug report, > search for flac. [...] > Nope, seems fine in 0.10. I also doublechecked that I can still > reproduce with 0.8. I'm a bit puzzled about that. I tried running valgrind over the pipeline to trace memory allocations with: SINK=alsasink or fakesink valgrind --leak-check=full --log-file=valgrind.log gst-launch-0.8 \ filesrc location=$PWD/01\ Electronic\ Performers.mp3 ! mad ! \ $SINK I saw only a minor leak with fakesink: ==15386== LEAK SUMMARY: ==15386==definitely lost: 36 bytes in 1 blocks. ==15386==indirectly lost: 120 bytes in 10 blocks. ==15386== possibly lost: 1,040 bytes in 26 blocks. ==15386==still reachable: 706,569 bytes in 13,815 blocks. ==15386== suppressed: 0 bytes in 0 blocks. a bigger one with alsasink: ==15665==definitely lost: 104 bytes in 3 blocks. ==15665==indirectly lost: 402 bytes in 30 blocks. ==15665== possibly lost: 25,280 bytes in 785 blocks. ==15665==still reachable: 759,390 bytes in 16,359 blocks. ==15665== suppressed: 0 bytes in 0 blocks. This is order of magnitudes below your experience. I suspect it might be a particular system configuration, such as an ALSA driver, causing this issue. Could you please give a "fakesink" command line a try and see whether the memory consumption still skyrockets? If you reproduce with any sink, please attach the valgind log. You may also try "osssink". Bye, -- Loïc Minier <[EMAIL PROTECTED]> Current Earth status: NOT DESTROYED
Bug#341772: quodlibet: severe memory leak
On Wed, 2006-02-01 at 02:28 +0100, Loïc Minier wrote: > Hi Dann, > > On Mon, Jan 09, 2006, dann frazier wrote: > > Also happens with flacs & mp3s - details are included in the bug report, > > search for flac. > [...] > > Nope, seems fine in 0.10. I also doublechecked that I can still > > reproduce with 0.8. > > I'm a bit puzzled about that. I tried running valgrind over the > pipeline to trace memory allocations with: > SINK=alsasink or fakesink > valgrind --leak-check=full --log-file=valgrind.log gst-launch-0.8 \ > filesrc location=$PWD/01\ Electronic\ Performers.mp3 ! mad ! \ > $SINK > > I saw only a minor leak with fakesink: > ==15386== LEAK SUMMARY: > ==15386==definitely lost: 36 bytes in 1 blocks. > ==15386==indirectly lost: 120 bytes in 10 blocks. > ==15386== possibly lost: 1,040 bytes in 26 blocks. > ==15386==still reachable: 706,569 bytes in 13,815 blocks. > ==15386== suppressed: 0 bytes in 0 blocks. > > a bigger one with alsasink: > ==15665==definitely lost: 104 bytes in 3 blocks. > ==15665==indirectly lost: 402 bytes in 30 blocks. > ==15665== possibly lost: 25,280 bytes in 785 blocks. > ==15665==still reachable: 759,390 bytes in 16,359 blocks. > ==15665== suppressed: 0 bytes in 0 blocks. > > This is order of magnitudes below your experience. I suspect it might > be a particular system configuration, such as an ALSA driver, causing > this issue. Or the fact that its ia64... > Could you please give a "fakesink" command line a try and see whether > the memory consumption still skyrockets? With fakesink, watching top w/ 1s samples, I see it use around 36M before it exits. So I think its safe to say its leaking memory at approximately the same rate. > If you reproduce with any > sink, please attach the valgind log. You may also try "osssink". Unfortunately there's no ia64 package for valgrind.
Bug#341772: quodlibet: severe memory leak
On Tue, Jan 31, 2006, dann frazier wrote: > Or the fact that its ia64... Oops. I asked some GStreamer folks running on amd64 to run the pipeline under valgrind/amd64, but they don't see the problem, so it seems it's purely ia64. I don't have specific ideas on how to debug this further, I could suggest using the debugging environment variables, that's all I think of now. -- Loïc Minier <[EMAIL PROTECTED]> Current Earth status: NOT DESTROYED
Bug#341772: quodlibet: severe memory leak
On Wed, 2006-02-01 at 11:11 +0100, Loïc Minier wrote: > On Tue, Jan 31, 2006, dann frazier wrote: > > Or the fact that its ia64... > > Oops. I asked some GStreamer folks running on amd64 to run the > pipeline under valgrind/amd64, but they don't see the problem, so it > seems it's purely ia64. I don't have specific ideas on how to debug > this further, I could suggest using the debugging environment > variables, that's all I think of now. What's the lifespan of gstreamer-0.8 - will it ship in etch?
Bug#341772: quodlibet: severe memory leak
Hi, On Wed, Feb 01, 2006, dann frazier wrote: > What's the lifespan of gstreamer-0.8 - will it ship in etch? The platform itself should. The timing is quite bad in general since the 0.8 series were nicely stabilized over the last year (a final stable release is scheduled for saturday, 0.8.12), but since GNOME 2.14 is due to ship with GStreamer 0.10, a lot of apps have rewritten their GStreamer backend against 0.10. Since I'm co-maintaining GNOME packages, and maintaining Rhythmbox, I am following what the GNOME apps will use in the coming months. My current feeling is that the next Rhythmbox release (due this week) should be built against 0.10, since I've seen some bugs that were fixed in the 0.10 backend only (not un the 0.8 backend), and it seems to be functionnally equivalent. Concerning totem, I think we will have to wait for GNOME 2.14's version to enable the 0.10 support, but I heard it works nicely. sound-juicer still has a couple of bugs against 0.10, but that should be fixed for GNOME 2.14 too. Given the timeline for etch, it seems feasible to ship GNOME 2.14, and hence most GNOME-ish apps will be using 0.10, however it's likely that the 0.8 platform will be in etch given the number of non-GNOME packages using it directly or through bindings. I hope you have enough elements to decide whether you want to invest some time fixing it. If you do decide to do so, it would be very nice to have this fix in the stable release 0.8.12 scheduled for saturday. Bye, -- Loïc Minier <[EMAIL PROTECTED]> Current Earth status: NOT DESTROYED
Bug#341772: quodlibet: severe memory leak
On Tue, Jun 06, 2006 at 10:29:46AM +0200, Lo?c Minier wrote: > Dann, > > Could you please check you still have the memory leak from #341772 with > the latest gst-plugins0.8 and gstreamer0.8? yes, it still exists with 0.8.12-2 -- dann frazier | HP Open Source and Linux Organization -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#341772: quodlibet: severe memory leak
Dann, Could you please check you still have the memory leak from #341772 with the latest gst-plugins0.8 and gstreamer0.8? Thanks, On Sun, Feb 12, 2006, Loïc Minier wrote: > Hi, > > On mar, jan 31, 2006, dann frazier wrote: > > With fakesink, watching top w/ 1s samples, I see it use around 36M > > before it exits. So I think its safe to say its leaking memory at > > approximately the same rate. > > You might want to check with the new upstream I uploaded which has some > mem leak fixes. It's gst-plugins0.8 and gstreamer0.8 0.8.12-1 > >Bye, > > -- > Loïc Minier <[EMAIL PROTECTED]> > Current Earth status: NOT DESTROYED > > -- Loïc Minier <[EMAIL PROTECTED]>
