Bug#713856: libavutil51: Pulseaudio provokes SIGFPE in libavutil

[Reinhard Tartler]

On Fri, Jul 12, 2013 at 3:52 PM, Dario Ernst <daddel9 at kanojo.de> wrote:
> Hello Reinhard,
>
> On 06/29/2013 08:21 AM, Reinhard Tartler wrote:
>> Can you please redo this backtrace with the packages "pulseaudio-dbg"
>> and "libav-dbg" installed? Without that, the backtrace has only
>> limited use.
>>
>> Also, please use both "bt full" and "bt" commands in the debugger.
>
> I have finally found some time to revert my libav packages to the Debian
> version from the (semi-working) DMO version. I've also installed
> pulseaudio-dbg (of pulseaudio 4.0-3). Here is the gdb output of run/bt
> and run/bt-full:
>
>
>  ~/ > gdb pulseaudio
> GNU gdb (GDB) 7.6-debian
> Copyright (C) 2013 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later
> <http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "x86_64-linux-gnu".
> For bug reporting instructions, please see:
> <http://www.gnu.org/software/gdb/bugs/>...
> Reading symbols from /usr/bin/pulseaudio...Reading symbols from
> /usr/lib/debug/usr/bin/pulseaudio...done.
> done.
> (gdb) run
> Starting program: /usr/bin/pulseaudio
> warning: no loadable sections found in added symbol-file system-supplied
> DSO at 0x7ffff7ffa000
> warning: Could not load shared library symbols for linux-vdso.so.1.
> Do you need "set solib-search-path" or "set sysroot"?
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
> process 16248 is executing new program: /usr/bin/pulseaudio
> warning: Could not load shared library symbols for linux-vdso.so.1.
> Do you need "set solib-search-path" or "set sysroot"?
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
> W: [pulseaudio] pid.c: Stale PID file, overwriting.
>
> Program received signal SIGFPE, Arithmetic exception.
> 0x00007fffeb9dc42a in av_samples_get_buffer_size () from
> /usr/lib/x86_64-linux-gnu/libavutil.so.51
> (gdb) bt
> #0  0x00007fffeb9dc42a in av_samples_get_buffer_size () from
> /usr/lib/x86_64-linux-gnu/libavutil.so.51
> #1  0x00007fffeb9dc5c3 in av_samples_alloc () from
> /usr/lib/x86_64-linux-gnu/libavutil.so.51
> #2  0x00007fffeca7022f in ?? () from
> /usr/lib/x86_64-linux-gnu/alsa-lib/libasound_module_pcm_a52.so
> #3  0x00007fffecc8526d in pa_alsa_set_hw_params (pcm_handle=0x78b490,
> ss=ss at entry=0x7fffffffd2a0,
> period_size=period_size at entry=0x7fffffffd290,
> buffer_size=buffer_size at entry=0x7fffffffd298,
>     tsched_size=tsched_size at entry=0, use_mmap=use_mmap at entry=0x0,
> use_tsched=use_tsched at entry=0x0,
> require_exact_channel_number=require_exact_channel_number at entry=true)
>     at modules/alsa/alsa-util.c:319

Are you absolutely sure that you have libav-dbg installed? I would
really need to see the locals and the stack frame of frames #0 and #1.
The source of the code in question can be seen here:

http://sources.debian.net/src/libav/6:0.8.7-1/libavutil/samplefmt.c?hl=96#L96

I wonder what kind of FPE this could be, maybe a division by zero? but
how can that happen?

>
> I have not been able to make too much sense from that, beeing a
> higher-level guy myself, i also couldn't quite follow the codeflow in
> libavutils a52 helper functions. So i really do hope that someone of you
> can make sense of this, and either fix it or get upstream to fix it (i
> am right in that i should not open an upstream bugreport, right?).

well, upstream's input would be great to have, but they will most
certainly ask you to try the latest HEAD of the master branch. Would
you be willing (and able) to recompile the alsa ac3 encoder plugin
against a custom build libacodec? If that fixes the problem, we could
proceed with identifying what commit to backport, if not, I would
think that upstream would be quite open to assist with finding a
solution to this problem.

Cheers,
Reinhard


-- 
regards,
    Reinhard