Bug#341772: quodlibet: severe memory leak

[dann frazier]

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.