Bug 373423 – media-sound/mpd-0.16.3 dies horribly while scanning with recent ffmpeg

• Status: RESOLVED FIXED
• Product: Gentoo Linux

[Description Mike MacDonald 2011-06-29 02:01:38 UTC]

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.

[Comment 1 Mike MacDonald 2011-06-29 02:02:30 UTC]

Created attachment 278585 [details]
revised ebuild

[Comment 2 Mike MacDonald 2011-06-29 02:02:54 UTC]

Created attachment 278587 [details, diff]
the patch

[Comment 3 Patrick 2011-06-30 06:01:57 UTC]

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

[Comment 4 Pacho Ramos 2011-07-01 11:34:38 UTC]

*** Bug 373675 has been marked as a duplicate of this bug. ***

[Comment 5 Christoph Mende (RETIRED) 2011-07-03 10:31:04 UTC]

Added the patch, thanks.

[Comment 6 Reimar Döffinger 2011-07-05 21:16:53 UTC]

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.

[Comment 7 Christoph Mende (RETIRED) 2011-07-06 07:27:40 UTC]

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

[Comment 8 Mike MacDonald 2011-07-06 17:24:25 UTC]

This also explains why mpd was eating 5G of RAM a few days ago.

[Comment 9 Christoph Mende (RETIRED) 2011-07-06 18:21:13 UTC]

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

[Comment 10 Reimar Döffinger 2011-07-06 18:27:09 UTC]

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.

[Comment 11 Mike MacDonald 2011-07-06 18:35:19 UTC]

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.

[Comment 12 Christoph Mende (RETIRED) 2011-07-09 22:01:01 UTC]

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

[Comment 13 Ed Catmur 2011-07-30 18:54:14 UTC]

I've entered bug 377103 for the underlying bug.