mpd-0.16.3 segfaults on scanning any files that ffmpeg recognizes but has trouble with. Reproducible: Always Steps to Reproduce: 1. start mpd 2. scan a directory with malformed media files in it 3. segfault Actual Results: mpd is killed by SIGSEGV. Expected Results: MPD library updated, with or without malformed file based on how damaged it is. There is an upstream bug for this: http://musicpd.org/mantis/view.php?id=3266 I have attached the patch from it and a revised ebuild using said patch.
Created attachment 278585 [details] revised ebuild
Created attachment 278587 [details, diff] the patch
I can confirm this on ~x86_64: media-video/ffmpeg-0.7.1 and media-sound/mpd-0.16.3 don't play together I downgraded to ffmpeg-0.7_rc1 and mpd is stable again, didn't try the patch - but hope it comes into the tree soon :)
*** Bug 373675 has been marked as a duplicate of this bug. ***
Added the patch, thanks.
This patch is wrong. The issue is a rather serious FFmpeg bug for which I just sent a patch to ffmpeg-devel. The patch you made fixes the crash but still leaves a memleak. To fix that you would also have to use avformat_open_input instead of av_open_input_stream but then it wouldn't compile against older FFmpeg versions anymore.
(In reply to comment #6) > This patch is wrong. The issue is a rather serious FFmpeg bug for which I just > sent a patch to ffmpeg-devel. > The patch you made fixes the crash but still leaves a memleak. > To fix that you would also have to use avformat_open_input instead of > av_open_input_stream but then it wouldn't compile against older FFmpeg versions > anymore. I know, I've told mpd upstream to use avformat_open_input on current ffmpeg. However, I won't remove the "wrong" patch. I prefer a leak over a crash.
This also explains why mpd was eating 5G of RAM a few days ago.
(In reply to comment #8) > This also explains why mpd was eating 5G of RAM a few days ago. Not necessarily, as far as I understand the situation, the leak is only triggered on db updates (if at all, considering mpd properly closes the AVFormatContext). My mpd consumes 10 MB RAM after several days uptime. Please watch your mpd if it happens again and run valgrind on it.
Upstream FFmpeg is fixed (all branches). The leak is a bit above 1kB per file opened (both success and failure). > considering mpd properly closes the AVFormatContext No, not the extra one that is created with unfixed FFmpeg, it never even sees the pointer to that one.
My library is ~50k tracks, and I was torrenting directly into the library, prompting constant rescans, at 1k*50k = ~50M per scan, I can see that as happening overnight.
(In reply to comment #10) > Upstream FFmpeg is fixed (all branches). > The leak is a bit above 1kB per file opened (both success and failure). Do you happen to know if anything bad happens now that ffmpeg gets pointers to NULL? And which ffmpeg version is fixed, 0.7.2/0.8.1?
I've entered bug 377103 for the underlying bug.