[gst-devel] RE : Re: Memory leaks

[SP GLE]

Here are tips to run valgrind ::

>>
#!/bin/sh

export GLIBCPP_FORCE_NEW=1
export GLIBCXX_FORCE_NEW=1
export G_SLICE=always-malloc
export G_DEBUG=gc-friendly

DP="/to/the/path/of/supp/files/"
SUPP="--suppressions=/usr/lib/valgrind/glibc-2.3.supp
--suppressions=${DP}gstreamer/common/gst.supp
--suppressions=${DP}gst-plugins-base/common/gst.supp
--suppressions=${DP}gst-plugins-good/common/gst.supp
--suppressions=${DP}gst-plugins-bad/common/gst.supp
--suppressions=${DP}gst-plugins-ugly/common/gst.supp
--suppressions=${DP}gst-ffmpeg/common/gst.supp"

OPTS="-v --trace-children=yes --track-fds=yes --time-stamp=yes
--tool=memcheck --leak-check=yes --leak-resolution=high
--freelist-vol=10000000 --show-reachable=yes --num-callers=40 ${SUPP}"

valgrind $OPTS $*

<<

I've tried the following cmd ::

 gst-launch audiotestsrc ! filesink location=/dev/null

I don't have any memleak. Which revision of GStreamer do you use ?

--- David Schleef <ds at schleef.org> a écrit :

> On Thu, Sep 20, 2007 at 06:03:29PM -0700, Steve Fink wrote:
> > I am trying to track down a slow memory leak in my gstreamer
> pipeline.
> > I attempted to simplify the pipeline, but it seems like *every*
> > pipeline I try leaks.
> > 
> > For example: audiotestsrc ! filesink location=/dev/null
> > 
> > leaked a very steady 750KB/sec. So I'll write that one off to a
> major
> > refcounting bug in filesink, perhaps.
> > 
> > audiotestsrc ! alsasink
> > 
> > leaked much more slowly, only 3.9KB/sec. Again, though, the leakage
> > rate was very steady.
> > 
> > For my element, I tracked down one leak by running with
> > GST_DEBUG='GST_REFCOUNTING:5' and grepping for '->80' (the first
> > refcount that reached 80, indicating that some object was
> accumulating
> > references over time.) That caught my one leak, but then that trick
> > didn't work anymore. Probably because I'm creating a bunch of
> objects
> > whose refcounts never get above 1 or 2, I suppose.
> > 
> > I even tried letting it leak for a while and then dumping out the
> > memory region that had grown. It had lots of 0xff in it and no
> text,
> > which didn't tell me much. (My audio signals tend to be 0x00 or
> > swerving all over the place, for what it's worth.)
> > 
> > I'm assuming that a PLAYING pipeline shouldn't use up more memory
> over time?
> > 
> > Any tips?
> 
> valgrind.
> 
> 
> 
> dave...
> 
> 
>
-------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
> 



      ______________________________________________________________________________ 
Stockage illimité de vos mails avec Yahoo! Mail. Changez aujourd'hui de mail !