with libav 9.5, we get the following output: leman - riders on the storm: the doors concerto - 09 - the end.mp3 Apr 22 17:00 : added jaz coleman/riders on the storm: the doors concerto/jaz coleman - riders on the storm: the doors concerto - 08 - strange days.mp3 Apr 22 17:02 : ffmpeg/flac: couldn't reallocate buffer of size 10687488 Apr 22 17:02 : ffmpeg/flac: couldn't reallocate buffer of size 10687488 Apr 22 17:02 : ffmpeg/flac: couldn't reallocate buffer of size 10687488 Apr 22 17:02 : ffmpeg/flac: couldn't reallocate buffer of size 10687488 Apr 22 17:02 : ffmpeg/flac: couldn't reallocate buffer of size 10687488
within valgrind --tool=memcheck, it got up to 12GB before i killed it. here's our seemingly-irrelevant output: [skynet](0) $ valgrind --tool=memcheck --trace-children=yes mpd --no-daemon ==29718== Memcheck, a memory error detector ==29718== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al. ==29718== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info ==29718== Command: mpd --no-daemon ==29718== daemon: cannot init supplementary groups of user "dank": Operation not permitted ^C ==29718== Invalid write of size 8 ==29718== at 0x8B72350: curl_multi_cleanup (in /usr/lib/x86_64-linux-gnu/libcurl-gnutls.so.4.3.0) ==29718== by 0x440D2B: ??? (in /usr/bin/mpd) ==29718== by 0x43FF08: ??? (in /usr/bin/mpd) ==29718== by 0x425FB7: ??? (in /usr/bin/mpd) ==29718== by 0xC33B6AC: (below main) (libc-start.c:227) ==29718== Address 0x0 is not stack'd, malloc'd or (recently) free'd ==29718== ==29718== ==29718== Process terminating with default action of signal 11 (SIGSEGV) ==29718== Access not within mapped region at address 0x0 ==29718== at 0x8B72350: curl_multi_cleanup (in /usr/lib/x86_64-linux-gnu/libcurl-gnutls.so.4.3.0) ==29718== by 0x440D2B: ??? (in /usr/bin/mpd) ==29718== by 0x43FF08: ??? (in /usr/bin/mpd) ==29718== by 0x425FB7: ??? (in /usr/bin/mpd) ==29718== by 0xC33B6AC: (below main) (libc-start.c:227) ==29718== If you believe this happened as a result of a stack ==29718== overflow in your program's main thread (unlikely but ==29718== possible), you can try to increase the size of the ==29718== main thread stack using the --main-stacksize= flag. ==29718== The main thread stack size used in this run was 8388608. ==29718== ==29718== HEAP SUMMARY: ==29718== in use at exit: 11,127,029 bytes in 2,890 blocks ==29718== total heap usage: 3,021,945 allocs, 3,019,055 frees, 60,612,742,457 bytes allocated ==29718== ==29718== LEAK SUMMARY: ==29718== definitely lost: 0 bytes in 0 blocks ==29718== indirectly lost: 0 bytes in 0 blocks ==29718== possibly lost: 46,060 bytes in 211 blocks ==29718== still reachable: 11,080,969 bytes in 2,679 blocks ==29718== suppressed: 0 bytes in 0 blocks ==29718== Rerun with --leak-check=full to see details of leaked memory ==29718== ==29718== For counts of detected and suppressed errors, rerun with: -v ==29718== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 2 from 2) Killed [skynet](137) $ running with --verbose now... -- nick black http://www.sprezzatech.com -- unix and hpc consulting to make an apple pie from scratch, you need first invent a universe. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org