[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#726733: av_register_all() segfaults on s390x in some cases (regression, causes FTBFS)

On Thu, Nov 14, 2013 at 5:26 PM, Florian Schlichting <fsfs@debian.org> wrote:
> Hi,
> mpd also FTBFS since I enabled the build tests in 0.18 (no regression
> here either).
> Reinhard asked for a backtrace, this is what I get in the
> sid_s390x-dchroot on zelenka:
> fsfs@zelenka ~/mpd-0.18.3 % gdb ./test/run_input core
> GNU gdb (GDB) 7.6.1 (Debian 7.6.1-1)
> 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 "s390x-linux-gnu".
> For bug reporting instructions, please see:
> <http://www.gnu.org/software/gdb/bugs/>...
> Reading symbols from /home/fsfs/mpd-0.18.3/test/run_input...done.
> [New LWP 16192]
> [New LWP 16193]
> warning: Could not load shared library symbols for linux-vdso64.so.1.
> Do you need "set solib-search-path" or "set sysroot"?
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/s390x-linux-gnu/libthread_db.so.1".
> Core was generated by `./test/run_input test/tmp/configure.bz2'.
> Program terminated with signal 11, Segmentation fault.
> #0  0x000003ff800040b4 in ?? ()
> (gdb) bt
> #0  0x000003ff800040b4 in ?? ()
> #1  0x000003fffbb2be68 in ?? () from /usr/lib/s390x-linux-gnu/libavcodec.so.54
> #2  0x000003fffbb1be68 in ?? () from /usr/lib/s390x-linux-gnu/libavcodec.so.54
> #3  0x000003fffbb07c34 in avcodec_register_all () from /usr/lib/s390x-linux-gnu/libavcodec.so.54
> #4  0x000003fffcfae996 in av_register_all () from /usr/lib/s390x-linux-gnu/libavformat.so.54
> #5  0x000000008000905e in input_ffmpeg_init (param=..., error=...) at src/input/FfmpegInputPlugin.cxx:78
> #6  0x0000000080004ed4 in input_stream_global_init (error=...) at src/InputInit.cxx:85
> #7  0x00000000800043bc in main (argc=<optimized out>, argv=0x3ffffaa98a8) at test/run_input.cxx:140

Unfortunately, the interesting parts are missing because of lack of
debug symbols. However, I was able to reproduce this issue by simply
invoking "avconv" (without any parameters):

(gdb) bt full
#0  0x000003ff80006650 in ?? ()
No symbol table info available.
#1  0x000003fffc9f8502 in ff_init_vlc_sparse
(vlc=vlc@entry=0x3fffcf655c0 <spectral_coeff_tab>,
nb_bits=nb_bits@entry=9, nb_codes=nb_codes@entry=9,
    bits=bits@entry=0x3fffcdc5988 <huffbits1>,
bits_wrap=bits_wrap@entry=1, bits_size=1, codes=0x3fffcdc5992
<huffcode1>, codes_wrap=1, codes_size=1, symbols=0x0,
    symbols_wrap=0, symbols_size=0, flags=4) at
        buf = <optimized out>
        i = <optimized out>
        j = <optimized out>
        ret = <optimized out>
#2  0x000003fffc9ec5ca in atrac3_init_static_data (codec=<optimized
out>) at /build/libav-9DWbf4/libav-9.10/libavcodec/atrac3.c:855
        i = 0
#3  0x000003fffc9d762c in avcodec_register_all () at
        initialized = 1
#4  0x00000000800068a0 in main (argc=<optimized out>,
argv=0x3ffffc1d498) at /build/libav-9DWbf4/libav-9.10/avconv.c:2358
        ret = <optimized out>
        ti = <optimized out>

at libavcodec/bitstream.c:283, there is a call to "av_malloc", but the
fact that the backtrace does not show anything related to the
implementation in libavutil/mem.c makes me uneasy.

BTW, the same problem still exists in libav 10~alpha1 from experimental.


Reply to: