18.07.12 20:06, Dan Dennedy написав(ла): > On Wed, Jul 18, 2012 at 9:31 AM, Maksym Veremeyenko<[email protected]> wrote: >> Hi, >> >> during debugging a program that uses mlt i found a lot of leaks in mlt >> framework. > > Some may be negligible one-time allocations that will free > automatically by kernel, but we try to use > mlt_factory_register_for_clean_up() to track those. Many will be in > dependencies and sometimes difficult or time-consuming to track down. > And maybe some are legitimate for which I welcome patches. > >> i prepared very small program that opens producer only (see attached) >> >> running valgrind >> >> valgrind -v --leak-check=full --error-limit=no --leak-resolution=high >> --show-reachable=yes ./mlt_play >> >> reports tons of errors, and among them: > > And each one requires analysis. Have you done that? I suggesting > removing modules that you do not need for your test in order to reduce > the noise level. > >> [...] >> ==8838== 40 bytes in 1 blocks are definitely lost in loss record 2 of 19 >> ==8838== at 0x4A074CD: malloc (vg_replace_malloc.c:236) >> ==8838== by 0xC0B8654: ??? >> ==8838== by 0xCA5E29F: ??? >> ==8838== by 0xC0B8209: ??? >> ==8838== by 0xC0B8576: ??? >> ==8838== by 0x4C48439: mlt_factory_producer (mlt_factory.c:291) >> ==8838== by 0xB67FB31: ??? >> ==8838== by 0xB67FE33: ??? >> ==8838== by 0x4C48439: mlt_factory_producer (mlt_factory.c:291) >> ==8838== by 0x4007C4: main (mlt_play.c:11) >> ==8838== >> ==8838== 40 bytes in 1 blocks are definitely lost in loss record 3 of 19 >> ==8838== at 0x4A074CD: malloc (vg_replace_malloc.c:236) >> ==8838== by 0xC0B8654: ??? >> ==8838== by 0xCA5E2B2: ??? >> ==8838== by 0xC0B8209: ??? >> ==8838== by 0xC0B8576: ??? >> ==8838== by 0x4C48439: mlt_factory_producer (mlt_factory.c:291) >> ==8838== by 0xB67FB31: ??? >> ==8838== by 0xB67FE33: ??? >> ==8838== by 0x4C48439: mlt_factory_producer (mlt_factory.c:291) >> ==8838== by 0x4007C4: main (mlt_play.c:11) >> ==8838== >> [...] >> >> is it a bug or i forget to free some resources? > > Those require further analysis, but it is not clear from that trace > where the problem lies except that it is in some producer. One thing > to check is that when you start a consumer, then frames in queues may > be holding references to the producer, and you need to ensure all > references to frames are released prior to normal process exit in > order to make the valgrind test happy. That should happen in > mlt_consumer_stop(). >
thanks for hints... i am trying to dig but currently without success :-(( -- ________________________________________ Maksym Veremeyenko ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Mlt-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mlt-devel
