mlt Memory leaks in melt CLI with and without input

Commit: 6b2310240433960b59b4f6f1f4945dfc9bd0462d CMAKE_BUILD_TYPE: Debug Sample used: https://samples.mplayerhq.hu/MXF/Quantel%20widescreen%20test.mxf Valgrind output edited for brevity. Running melt so that it only prints usage:

$ valgrind --leak-check=full --suppressions=suppress melt
HEAP SUMMARY:
    in use at exit: 253,582 bytes in 584 blocks
  total heap usage: 4,754 allocs, 4,170 frees, 1,177,549 bytes allocated

4,046 (32 direct, 4,014 indirect) bytes in 1 blocks are definitely lost in loss record 262 of 269
   at 0x483AB65: calloc (vg_replace_malloc.c:760)
   by 0x486E200: mlt_properties_new (mlt_properties.c:123)
   by 0x4876DD7: mlt_repository_init (mlt_repository.c:73)
   by 0x485E619: mlt_factory_init (mlt_factory.c:209)
   by 0x10CD35: main (melt.c:921)

LEAK SUMMARY:
   definitely lost: 32 bytes in 1 blocks
   indirectly lost: 4,014 bytes in 15 blocks
     possibly lost: 0 bytes in 0 blocks
   still reachable: 1,952 bytes in 22 blocks
                      of which reachable via heuristic:
                        newarray           : 1,536 bytes in 16 blocks
        suppressed: 247,584 bytes in 546 blocks

With actual input:

$ valgrind --leak-check=full --suppressions=suppress melt -producer avformat:Quantel\ widescreen\ test.mxf out=1 -consumer null terminate_on_pause=1
HEAP SUMMARY:
    in use at exit: 353,220 bytes in 1,289 blocks
  total heap usage: 22,616 allocs, 21,327 frees, 101,383,279 bytes allocated

32 bytes in 2 blocks are definitely lost in loss record 126 of 304
   at 0x483AB65: calloc (vg_replace_malloc.c:760)
   by 0x485CF27: mlt_deque_init (mlt_deque.c:64)
   by 0x802963C: ???
   by 0x80273B7: ???
   by 0x8024B90: ???
   by 0x48772D2: mlt_repository_create (mlt_repository.c:248)
   by 0x485E904: mlt_factory_producer (mlt_factory.c:345)
   by 0xF79C555: ???
   by 0xF79CC01: ???
   by 0x48772D2: mlt_repository_create (mlt_repository.c:248)
   by 0x485E904: mlt_factory_producer (mlt_factory.c:345)
   by 0xF79D035: ???

32 bytes in 2 blocks are definitely lost in loss record 127 of 304
   at 0x483AB65: calloc (vg_replace_malloc.c:760)
   by 0x485CF27: mlt_deque_init (mlt_deque.c:64)
   by 0x8029651: ???
   by 0x80273B7: ???
   by 0x8024B90: ???
   by 0x48772D2: mlt_repository_create (mlt_repository.c:248)
   by 0x485E904: mlt_factory_producer (mlt_factory.c:345)
   by 0xF79C555: ???
   by 0xF79CC01: ???
   by 0x48772D2: mlt_repository_create (mlt_repository.c:248)
   by 0x485E904: mlt_factory_producer (mlt_factory.c:345)
   by 0xF79D035: ???

2,144 bytes in 2 blocks are definitely lost in loss record 288 of 304
   at 0x483AEB8: memalign (vg_replace_malloc.c:906)
   by 0x483AFCE: posix_memalign (vg_replace_malloc.c:1070)
   by 0x900BB64: ???
   by 0x9873E33: ???
   by 0x802A19C: ???
   by 0x8029614: ???
   by 0x80273B7: ???
   by 0x8024B90: ???
   by 0x48772D2: mlt_repository_create (mlt_repository.c:248)
   by 0x485E904: mlt_factory_producer (mlt_factory.c:345)
   by 0xF79C555: ???
   by 0xF79CC01: ???

2,144 bytes in 2 blocks are definitely lost in loss record 289 of 304
   at 0x483AEB8: memalign (vg_replace_malloc.c:906)
   by 0x483AFCE: posix_memalign (vg_replace_malloc.c:1070)
   by 0x900BB64: ???
   by 0x9873E33: ???
   by 0x802FC75: ???
   by 0x803020E: ???
   by 0x80303F4: ???
   by 0x486B9EE: producer_get_frame (mlt_producer.c:663)
   by 0x4878735: mlt_service_get_frame (mlt_service.c:581)
   by 0x486BC2E: producer_get_frame (mlt_producer.c:714)
   by 0x4878735: mlt_service_get_frame (mlt_service.c:581)
   by 0x486A1F6: producer_get_frame (mlt_playlist.c:2066)

2,316 (2,144 direct, 172 indirect) bytes in 2 blocks are definitely lost in loss record 290 of 304
   at 0x483AEB8: memalign (vg_replace_malloc.c:906)
   by 0x483AFCE: posix_memalign (vg_replace_malloc.c:1070)
   by 0x900BB64: ???
   by 0x9873E33: ???
   by 0x802D1A1: ???
   by 0x802DE6B: ???
   by 0x80303DE: ???
   by 0x486B9EE: producer_get_frame (mlt_producer.c:663)
   by 0x4878735: mlt_service_get_frame (mlt_service.c:581)
   by 0x486BC2E: producer_get_frame (mlt_producer.c:714)
   by 0x4878735: mlt_service_get_frame (mlt_service.c:581)
   by 0x486A1F6: producer_get_frame (mlt_playlist.c:2066)

4,046 (32 direct, 4,014 indirect) bytes in 1 blocks are definitely lost in loss record 293 of 304
   at 0x483AB65: calloc (vg_replace_malloc.c:760)
   by 0x486E200: mlt_properties_new (mlt_properties.c:123)
   by 0x4876DD7: mlt_repository_init (mlt_repository.c:73)
   by 0x485E619: mlt_factory_init (mlt_factory.c:209)
   by 0x10CD35: main (melt.c:921)

LEAK SUMMARY:
   definitely lost: 6,528 bytes in 11 blocks
   indirectly lost: 4,186 bytes in 17 blocks
     possibly lost: 0 bytes in 0 blocks
   still reachable: 1,952 bytes in 22 blocks
                      of which reachable via heuristic:
                        newarray           : 1,536 bytes in 16 blocks
        suppressed: 340,554 bytes in 1,239 blocks

Suppressions used:

{
   Ignore dlopen bug.
   Memcheck:Leak
   ...
   fun:_dl_open
   ...
}
{
   Ignore dlopen bug.
   Memcheck:Leak
   ...
   fun:_dl_init
   ...
}

Oct 28 '21 07:10 Tjoppen

Is there an ETA on this ?

Jul 03 '23 18:07 luzpaz

I am confident that this is not a priority for anyone and nobody plans to work on it. Unless someone volunteers, I recommend that we close this as "won't fix"

Jul 04 '23 18:07 bmatherly

Maybe adding this to a 'Known Issues' list so folks are made aware of the pre-existence of this big?

Jul 07 '23 19:07 luzpaz

I am confident that this is not a priority for anyone and nobody plans to work on it. Unless someone volunteers, I recommend that we close this as "won't fix"

Usually issues like these are related to larger issues hiding in the code. It also makes debugging more serious leaks more difficult.

Jul 12 '23 20:07 Tjoppen