Bug#774216: mpv: uses lots of RAM

Tue Dec 30 12:32:22 UTC 2014

Package: mpv
Version: 0.6.2-2

Hi,

When using mpv to play a movie after an hour it has several GB of
RAM in use.  When I then quiet it seems to clean up part at least
a part of it.  I see that it goes in D state to swap things back
in as it reduces the memory usage.  So I think it or one of it's
libraries is holding on to something that it might not need
anymore.

I also tried to check for memory leaks, and it seems there are
some, but it's clearly not in the order of RAM usage that I saw.

Trying with just playing aac audio for about 10 seconds:
==21568== HEAP SUMMARY:
==21568==     in use at exit: 119,235 bytes in 748 blocks
==21568==   total heap usage: 48,153 allocs, 47,405 frees, 48,049,433 bytes allocated
==21568== 
==21568== 1,489 (16 direct, 1,473 indirect) bytes in 1 blocks are definitely lost in loss record 88 of 95
==21568==    at 0x4C28C20: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==21568==    by 0x5907B36: pa_xmalloc (in /usr/lib/x86_64-linux-gnu/libpulse.so.0.17.3)
==21568==    by 0x58E5DEA: pa_format_info_new (in /usr/lib/x86_64-linux-gnu/libpulse.so.0.17.3)
==21568==    by 0x155F8B: ??? (in /usr/bin/mpv)
==21568==    by 0x150FDF: ??? (in /usr/bin/mpv)
==21568==    by 0x151322: ??? (in /usr/bin/mpv)
==21568==    by 0x1860CD: ??? (in /usr/bin/mpv)
==21568==    by 0x186826: ??? (in /usr/bin/mpv)
==21568==    by 0x19E324: ??? (in /usr/bin/mpv)
==21568==    by 0x196C37: ??? (in /usr/bin/mpv)
==21568==    by 0x197D5A: ??? (in /usr/bin/mpv)
==21568==    by 0xC8BCB44: (below main) (libc-start.c:287)
==21568== 
==21568== LEAK SUMMARY:
==21568==    definitely lost: 16 bytes in 1 blocks
==21568==    indirectly lost: 1,473 bytes in 17 blocks
==21568==      possibly lost: 0 bytes in 0 blocks
==21568==    still reachable: 117,746 bytes in 730 blocks
==21568==         suppressed: 0 bytes in 0 blocks

When playing a flac file for 10 seconds which contains an embedded cover (mjpeg), I get:
==31287== HEAP SUMMARY:
==31287==     in use at exit: 177,257 bytes in 1,627 blocks
==31287==   total heap usage: 205,547 allocs, 203,920 frees, 117,425,619 bytes allocated
==31287== 
==31287== 63 bytes in 4 blocks are definitely lost in loss record 93 of 179
==31287==    at 0x4C28C20: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==31287==    by 0xC91C819: strdup (strdup.c:42)
==31287==    by 0x1E8A9AEA: ??? (in /usr/lib/x86_64-linux-gnu/dri/i965_dri.so)
==31287==    by 0x1E8ABC9E: ??? (in /usr/lib/x86_64-linux-gnu/dri/i965_dri.so)
==31287==    by 0x1E8B56FB: ??? (in /usr/lib/x86_64-linux-gnu/dri/i965_dri.so)
==31287==    by 0x1E74E47E: ??? (in /usr/lib/x86_64-linux-gnu/dri/i965_dri.so)
==31287==    by 0x1E838822: ??? (in /usr/lib/x86_64-linux-gnu/dri/i965_dri.so)
==31287==    by 0x1E9888E5: ??? (in /usr/lib/x86_64-linux-gnu/dri/i965_dri.so)
==31287==    by 0x1E98937B: ??? (in /usr/lib/x86_64-linux-gnu/dri/i965_dri.so)
==31287==    by 0x1E943A47: ??? (in /usr/lib/x86_64-linux-gnu/dri/i965_dri.so)
==31287==    by 0x1EA928: ??? (in /usr/bin/mpv)
==31287==    by 0x1EAC8A: ??? (in /usr/bin/mpv)
==31287== 
==31287== 990 bytes in 22 blocks are definitely lost in loss record 141 of 179
==31287==    at 0x4C2AD10: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==31287==    by 0x1E8C52A1: ??? (in /usr/lib/x86_64-linux-gnu/dri/i965_dri.so)
==31287==    by 0x1E8C564C: ??? (in /usr/lib/x86_64-linux-gnu/dri/i965_dri.so)
==31287==    by 0x1E8C5713: ??? (in /usr/lib/x86_64-linux-gnu/dri/i965_dri.so)
==31287==    by 0x1E87CA32: ??? (in /usr/lib/x86_64-linux-gnu/dri/i965_dri.so)
==31287==    by 0x1E87D024: ??? (in /usr/lib/x86_64-linux-gnu/dri/i965_dri.so)
==31287==    by 0x1E8818F6: ??? (in /usr/lib/x86_64-linux-gnu/dri/i965_dri.so)
==31287==    by 0x1E867B89: ??? (in /usr/lib/x86_64-linux-gnu/dri/i965_dri.so)
==31287==    by 0x1E86E3A7: ??? (in /usr/lib/x86_64-linux-gnu/dri/i965_dri.so)
==31287==    by 0x1E86E38F: ??? (in /usr/lib/x86_64-linux-gnu/dri/i965_dri.so)
==31287==    by 0x1E865A40: ??? (in /usr/lib/x86_64-linux-gnu/dri/i965_dri.so)
==31287==    by 0x1E8678ED: ??? (in /usr/lib/x86_64-linux-gnu/dri/i965_dri.so)
[...]
13 more in i965_dri
[...]
==31287== 1,485 (16 direct, 1,469 indirect) bytes in 1 blocks are definitely lost in loss record 162 of 179
==31287==    at 0x4C28C20: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==31287==    by 0x5907B36: pa_xmalloc (in /usr/lib/x86_64-linux-gnu/libpulse.so.0.17.3)
==31287==    by 0x58E5DEA: pa_format_info_new (in /usr/lib/x86_64-linux-gnu/libpulse.so.0.17.3)
==31287==    by 0x155F8B: ??? (in /usr/bin/mpv)
==31287==    by 0x150FDF: ??? (in /usr/bin/mpv)
==31287==    by 0x151322: ??? (in /usr/bin/mpv)
==31287==    by 0x1860CD: ??? (in /usr/bin/mpv)
==31287==    by 0x186826: ??? (in /usr/bin/mpv)
==31287==    by 0x19E324: ??? (in /usr/bin/mpv)
==31287==    by 0x196C37: ??? (in /usr/bin/mpv)
==31287==    by 0x197D5A: ??? (in /usr/bin/mpv)
==31287==    by 0xC8BCB44: (below main) (libc-start.c:287)
[...]
4 other in i965_dri
[...]
==31287== 
==31287== LEAK SUMMARY:
==31287==    definitely lost: 20,869 bytes in 467 blocks
==31287==    indirectly lost: 1,469 bytes in 17 blocks
==31287==      possibly lost: 0 bytes in 0 blocks
==31287==    still reachable: 154,919 bytes in 1,143 blocks
==31287==         suppressed: 0 bytes in 0 blocks

When having played it completly (4:53), it shows:
==7177==     in use at exit: 177,435 bytes in 1,633 blocks
==7177==   total heap usage: 839,337 allocs, 837,704 frees, 282,224,597 bytes allocated
[...]
==7177== LEAK SUMMARY:
==7177==    definitely lost: 20,997 bytes in 468 blocks
==7177==    indirectly lost: 1,469 bytes in 17 blocks
==7177==      possibly lost: 0 bytes in 0 blocks
==7177==    still reachable: 154,969 bytes in 1,148 blocks
==7177==         suppressed: 0 bytes in 0 blocks

When playing a flac file without the embedded cover it looks like
the aac case above.

Playing a MOV or X264 file results in very simular behaviour as
showing the cover.

So it looks to me that there is at least some memory leak.

When watching it, it might be growing it's memory usage slowly,
but it seems to go way slower than I expected.

Anyway, I had this problem at least twice now that I had to quit
it because it was using too much RAM and it started to slow down
everything because it was swapping.

This is using libpulse0 5.0-13 and libgl1-mesa-dri
10.3.2-1 if that's relevant.

Kurt