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.