Huge memory leak sometime after starting a pipeline
Sebastian Dröge
sebastian at centricular.com
Thu Nov 6 02:47:47 PST 2014
On Do, 2014-11-06 at 11:33 +0100, Sergei Vorobyov wrote:
> Sorry to say but the universal (on this list) recipe to use valgrind is
> useless, like a hammer to drive screws.
>
> Point is, to see "leaks", you need to stop your application, in which case
> GStreamer produces thousands (miles) of messages of the kind:
> [...]
>
> even though you make a clean exit with _unrefs of all kinds and gst_deinit
> (), and the application does not leak at all (if you don't stop it and run
> indefinitely).
>
> Sure (by the end of the day) you can suppress any kind of messages you want
> to ignore, but this hardly approaches you to the solution of the problem.
> Should you take the above message seriously or ignore? Can you ask
> GStreamer developers "take seriously or ignore?" about each of 100.000 such
> messages?
The big leaks will be at the top, the small ones at the bottom. If
there's nothing big at the top you have a problem and valgrind's
memcheck tool won't be useful for you. And as I said last time already,
valgrind is not solving all problems but it's a good start... and if it
doesn't help (it does help in like 90% of the cases!) it still gives you
hints at where *not* to waste your time looking. Debugging memory leaks
is not trivial, use any help that you can get.
Also try to simplify your pipeline to get a minimal testcase that
reproduces the problem. And also see my mention of massif, which will be
useful while the application is running.
> I observed (without valgrind) a curious thing: the same application leaks
> as hell on Intel's HD4400 IGP (NUC) with Intel's driver, but does not leak
> at all on AMD Radeon, nor on NVidia. As I said, in all three cases valgrind
> uselessly reports miles of possibly and definitely lost blocks, which makes
> all three different cases completely indistinguishable.
>
> Check if you are using Intel's graphics HW. Maybe this is the reason.
> Despite the developers claim that GStreamer runs equally good on any
> hardware.
Sure there might be a driver bug in the Intel driver. Like there can
also be driver bugs in the others. Apart from those things GStreamer
does not care at all what hardware you use, and in general most of us
are using Intel hardware.
Regarding my comment to simplify your pipeline... try to reproduce the
leak without rendering video to the screen and just a fakesink. And try
to reproduce the leak with a much simpler source but displaying on the
screen. Dividing a problem into subproblems does not only help with
quicksort ;)
--
Sebastian Dröge, Centricular Ltd · http://www.centricular.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 949 bytes
Desc: This is a digitally signed message part
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20141106/19449e47/attachment.sig>
More information about the gstreamer-devel
mailing list