GNOME Bugzilla – Bug 729647
memory leak while playing in a loop mp4 with ec3 & h264
Last modified: 2016-05-22 18:29:48 UTC
Created attachment 275976 [details] valgrind output + main.cpp Hi, I have a simple sniped (see attachment) that is playing mp4 with ec3 & h264 in a infinite loop. The looping is implemented using seek after EOF. And is outputing only video. On Linux except some initialization leaks everything works fine. Snipped was looping more than 4 days without significant memory leaks (if any). (see attachment for leaks from valgrind - comes from short tests, with 5 loops, for me there are only startup leaks) On Windows same snipped with same pipline (except video sink) is leaking a lot. After 6h I got an error from glib that it can not allocate more than 1.5GB. Is it a known issue? How I can check on win where are these leaks?
How are you measuring the leaks on windows? Can you reproduce the leak with simpler pipelines/scenarios? If the videosink is the only element that changed from the 2 pipelines, maybe trying: gst-launch-1.0 videotestsrc ! <same caps format> ! <your windows video sink> might show the issue?
Created attachment 276652 [details] pipeline graph
Can you re-run valgrind with these environment variables set ? G_DEBUG=gc-friendly G_SLICE=always-malloc
Also the output of massif would be interesting if valgrind does not show any bigger leaks
Hi again in attachment you can find one more from valgrind. Crated with suggested settings : G_DEBUG=gc-friendly G_SLICE=always-malloc. Name : traces_g_debug_g_slice2.log. I see that one of my comments did not reach guzilla. So I wrote then that I tested it on windows with simples pipleline which was gst-launch-1.0 videotestsrc ! d2dvideosink (graph contained only these two nodes) In result, it was able to loop longer than my example. About 1,5d. But in windows exploerer I observed that memory consumption was increasing and increasing... After this time (about 1,7G) I got an error that G_SLICE can not allocate more memory (reqest was for about 4-5KB)
Created attachment 276855 [details] traces from valgrind with G_DEBUG=gc-friendly G_SLICE=always-malloc
Created attachment 276874 [details] correct valgrind output with G_DEBUG=gc-friendly G_SLICE=always-malloc
(In reply to comment #7) > Created an attachment (id=276874) [details] > correct valgrind output with G_DEBUG=gc-friendly G_SLICE=always-malloc There's no real memory leak in here. So somewhere memory is accumulating without being lost... can you also run with massif to see where that much memory is allocated and not freed?
Created attachment 277056 [details] massif output Hi, in attachment you can find outputs from massif. Please note that I am reporting bug against WINDOWS. It is also visible when you call : gst-launch-1.0 videotestsrc ! d3dvideosink Wait some significant amount of time (eg.1-2h) and then go to WindowsTaskManager Wait sth like 1,5h day and then you will have allocation error. In case I build more complex pipline using my mp4 the error occurs ealier (sth like 6h).
Ok, so it seems like raw video buffers are leaked somewhere
Actually I misread the output. There seems to be no increasing memory usage at all, it's always staying around 16-17MB heap. So you are saying that this problem only happens on Windows, right?
Yes, it is only on windows.
rado, any chance you could re-test this with a recent (>= 1.7.90) release? I think this issue might have been fixed in the meantime.