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().

-- 
+-DRD-+

------------------------------------------------------------------------------
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

Reply via email to