GNOME Bugzilla – Bug 618832
Memory Leak
Last modified: 2010-08-26 17:27:16 UTC
Created attachment 161199 [details] Memory Leak Test There's a slow memory leak when you switch a pipeline from NULL -> PLAYING -> NULL -> PLAYING, etc. I've attached a small C program derived from one of the examples that demonstrates the issue. It takes a while for it to manifest itself. I ran a sample movie which I'll attempt to attach here for over a day and it started out using 8.5 MB of memory (after several loops of the video) and is now at 16 MB. The problem is exacerbated when you have multiple pipelines going at the same time in your application. For a typical file, just seeking back to the beginning hasn't shown any noticeable memory leak, but I deal with sources that aren't seekable and my application constantly switches between sources, so seeking isn't always an option. My program will be running on machines that pretty much will be running 24/7 until an admin stops it or the hardware fails. Thus a slow leak could become a real problem. I'm not particularly adept at debugging C apps, but I am attempting to debug it further using valgrind and I'll post anything further that I do find, but I would appreciate your help in identifying and resolving the issue. I've seen it appear both under windows and linux both using xvimagesink, directdrawsink, dshowvideosink, and fakesink. I'm using the latest released version of core (0.10.29) and the latest released version of the other libs. My tests have been on ubuntu 8 (hardy), windows xp, and windows 7.
Created attachment 161200 [details] Sample Movie
Using the latest releases/pre-releases, I only see some minor leakage in gst-ffmpeg. 10 iterations of your movie yield: tpm@zingle:~/gst/releases/code$ libtool --mode=link gcc `pkg-config --cflags --libs gstreamer-0.10` -o leak leak.c -Wall -ggdb tpm@zingle:~/gst/releases/code$ G_SLICE=always-malloc valgrind --suppressions=../gstreamer/common/gst.supp --leak-check=yes .libs/leak file:///home/tpm/samples/618832-example.mov ==6431== Memcheck, a memory error detector ==6431== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al. ==6431== Using Valgrind-3.5.0-Debian and LibVEX; rerun with -h for copyright info ==6431== Command: .libs/leak file:///home/tpm/samples/618832-example.mov ==6431== ** Message: received EOS ** Message: received EOS ** Message: received EOS ** Message: received EOS ** Message: received EOS ** Message: received EOS ** Message: received EOS ** Message: received EOS ** Message: received EOS ** Message: received EOS ** Message: stopping ==6431== ==6431== HEAP SUMMARY: ==6431== in use at exit: 2,485,102 bytes in 32,075 blocks ==6431== total heap usage: 2,340,489 allocs, 2,308,414 frees, 226,123,231 bytes allocated ==6431== ==6431== 720 (120 direct, 600 indirect) bytes in 5 blocks are definitely lost in loss record 4,973 of 5,097 ==6431== at 0x4C221A7: malloc (vg_replace_malloc.c:195) ==6431== by 0x5CF0504: g_malloc (gmem.c:132) ==6431== by 0x5D05409: g_slice_alloc (gslice.c:836) ==6431== by 0x5CE5485: g_list_append (glist.c:242) ==6431== by 0xB5FDCF7: gst_ffmpegdec_video_frame (gstffmpegdec.c:1590) ==6431== by 0xB600240: gst_ffmpegdec_frame (gstffmpegdec.c:2187) ==6431== by 0xB601478: gst_ffmpegdec_drain (gstffmpegdec.c:2282) ==6431== by 0xB60193C: gst_ffmpegdec_chain (gstffmpegdec.c:2463) ==6431== by 0x4E836EC: gst_pad_chain_data_unchecked (gstpad.c:4131) ==6431== by 0x4E83FAD: gst_pad_push_data (gstpad.c:4360) ==6431== by 0x8DF26C5: gst_multi_queue_loop (gstmultiqueue.c:919) ==6431== by 0x4EABE3A: gst_task_func (gsttask.c:271) ==6431== ==6431== 720 (120 direct, 600 indirect) bytes in 5 blocks are definitely lost in loss record 4,974 of 5,097 ==6431== at 0x4C221A7: malloc (vg_replace_malloc.c:195) ==6431== by 0x5CF0504: g_malloc (gmem.c:132) ==6431== by 0x5D05409: g_slice_alloc (gslice.c:836) ==6431== by 0x5CE5485: g_list_append (glist.c:242) ==6431== by 0xB5FDCF7: gst_ffmpegdec_video_frame (gstffmpegdec.c:1590) ==6431== by 0xB600240: gst_ffmpegdec_frame (gstffmpegdec.c:2187) ==6431== by 0xB601478: gst_ffmpegdec_drain (gstffmpegdec.c:2282) ==6431== by 0xB602ABF: gst_ffmpegdec_sink_event (gstffmpegdec.c:2327) ==6431== by 0x4E80DA5: gst_pad_send_event (gstpad.c:5052) ==6431== by 0x4E81272: gst_pad_push_event (gstpad.c:4908) ==6431== by 0x8DF2326: gst_multi_queue_loop (gstmultiqueue.c:942) ==6431== by 0x4EABE3A: gst_task_func (gsttask.c:271) ==6431== ==6431== LEAK SUMMARY: ==6431== definitely lost: 240 bytes in 10 blocks ==6431== indirectly lost: 1,200 bytes in 50 blocks ==6431== possibly lost: 0 bytes in 0 blocks ==6431== still reachable: 477,957 bytes in 6,604 blocks ==6431== suppressed: 2,005,705 bytes in 25,411 blocks ==6431== Reachable blocks (those to which a pointer was found) are not shown. ==6431== To see them, rerun with: --leak-check=full --show-reachable=yes ==6431== ==6431== For counts of detected and suppressed errors, rerun with: -v ==6431== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 378 from 285)
The only leak I could see was one in gst-ffmpeg I just fixed (it was leaking around 240bytes every iteration): commit f9c246724147273700c3d4b12ec8c4976f3ac30b Author: Edward Hervey <bilboed@bilboed.com> Date: Mon May 17 19:42:41 2010 +0200 ffmpegdec: Don't leak the GstDataPassThrough items
what does the "iteration" means in this case? every NULL -> PLAYING transition?
> what does the "iteration" means in this case? every NULL -> PLAYING transition? That's what I tested, yes.
David, can you confirm whether this leak is gone ?
I'm still working it. I'll update this as soon as I can confirm if the problem is solved.
David, ping?
does still happen the problem? any news david?
I haven't observed it for a while, but then again, I changed my strategy entirely. So it may or may not exist, but I haven't seen it in what I'm doing these days. If it pops up again, I'll submit a new bug.
Closing this bug report as no further information has been provided. Please feel free to reopen this bug if you can provide the information asked for. Thanks!