Bug#556198: mpd: segfault when trying to play a m4a (AAC-LC) file

[Reinhard Tartler]

Max Kellermann <max at duempel.org> writes:

> On 2009/11/14 15:05, Frank Dietrich <bits_n_bytes at gmx.de> wrote:
>> The file is around 80 MB. In this case I think it's better you get it
>> directly from the source.
>> http://www.radio538.nl/clubnouveau/podcast.xml
>> 
>> The problem seems not related to this file itself, as other *.m4a also
>> lead mpd into a segfault.
>> If you need more examples I can provide them to you.
>
> Thanks, I downloaded the file, and I can reproduce the problem.

I've downloaded it as well, but cannot reproduce it with ffplay. I
conclude that mpd uses libavformat in a different way. This may or may
not be a bug in mpd.

>  Since libmp4ff isn't part of libfaad anymore in sid, MPD uses ffmpeg
> (libavformat) for decoding that file.  Unfortunately, I cannot help
> you, because this is a bug in libavcodec.
>
> Here's the backtrace (not very useful):
>
>  (gdb) bt
>  #0  0xf7608455 in ?? () from /usr/lib/i686/cmov/libavcodec.so.52
>  #1  0x3f786c32 in ?? ()
>  Backtrace stopped: previous frame inner to this frame (corrupt stack?)
>
> This originates from the function avcodec_decode_audio2() called by
> MPD in src/decoder/ffmpeg_plugin.c, ffmpeg_send_packet().

how did you find this out?

> With valgrind, this problem does not occur.  libavformat
> 0.svn20080206-18 (Lenny) is unaffected, same for svn r20416
> (2009-10-29).

I guess this is svn from trunk?

>  I suggest upgrading the libavformat52 package to the latest snapshot.

not an option, this would probably break a lot of packages currently in
debian. help here is welcome.

anyway, I did some googling on this issue, and found this:

http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2009-January/059640.html

This made me I look at the whole context of the mpd source calling
avcodec_decode_audio2():

,----
| static enum decoder_command
| ffmpeg_send_packet(struct decoder *decoder, struct input_stream *is,
| 		   const AVPacket *packet,
| 		   AVCodecContext *codec_context,
| 		   const AVRational *time_base)
| {
| 	enum decoder_command cmd = DECODE_COMMAND_NONE;
| 	int position;
| 	uint8_t audio_buf[(AVCODEC_MAX_AUDIO_FRAME_SIZE * 3) / 2];
| 	int len, audio_size;
| 	uint8_t *packet_data;
| 	int packet_size;
| 
| 	packet_data = packet->data;
| 	packet_size = packet->size;
| 
| 	while ((packet_size > 0) && (cmd == DECODE_COMMAND_NONE)) {
| 		audio_size = sizeof(audio_buf);
| 		len = avcodec_decode_audio2(codec_context,
| 					    (int16_t *)audio_buf,
| 					    &audio_size,
| 					    packet_data, packet_size);
| 
| 		if (len < 0) {
| 			/* if error, we skip the frame */
| 			g_message("decoding failed\n");
| 			break;
| 		}
`----

now compare this to the documentation of avcodec_decode_audio2():

 * @note You might have to align the input buffer \p buf and output buffer \p
 * samples. The alignment requirements depend on the CPU: On some CPUs it isn't
 * necessary at all, on others it won't work at all if not aligned and on others
 * it will work but it will have an impact on performance. In practice, the
 * bitstream should have 4 byte alignment at minimum and all sample data should
 * be 16 byte aligned unless the CPU doesn't need it (AltiVec and SSE do). If
 * the linesize is not a multiple of 16 then there's no sense in aligning the
 * start of the buffer to 16.


It seems to me that the output buffer is simply not aligned, which makes
mpd crash when using the MMX optimized functions of ffmpeg. If I'm
right, the crash should just disappear if you disable
/usr/lib/i686/cmov/libavcodec.so.52, so that mpd falls back to the
non-MMX capable version /usr/lib/libavcodec.so.52.

Reporter: can you please rm /usr/lib/i686/cmov/libavcodec.so.52 and see
if the crash still occurs? I don't use mpd myself, so I can only do
(educated) guesses.

-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4