On 11/3/17, Thilo Borgmann <thilo.borgm...@mail.de> wrote: > Am 02.11.17 um 21:32 schrieb Umair Khan: >> Hi, >> >> On Fri, Oct 20, 2017 at 1:44 AM, Ronald S. Bultje <rsbul...@gmail.com> >> wrote: >>> >>> Hi, >>> >>> On Thu, Oct 19, 2017 at 4:03 PM, Umair Khan <omerj...@gmail.com> wrote: >>> >>>> I tried decoding the file in both the cases and I don't see any >>>> address related error in the console while decoding. Following is the >>>> output after I apply the patch :- >>>> >>> [..] >>> >>>> Is there something which I'm missing? >>>> >>> >>> You need to run under valgrind or compile with address sanitizer support: >>> configure --toolchain=gcc-asan or --toolchain=clang-asan, depending on >>> the >>> name of clang on your system. >> >> Thanks for the help. I was finally able to reproduce the error. >> >> I have been trying to debug this heap-buffer-overflow error for some >> days. I have finally found the source of the issue at least. >> >> https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/alsdec.c#L934 >> >> raw_samples pointer is overflowing inside that loop. I haven't thought >> of a proper fix for this yet. I'll look at the documentation to >> understand the logic first. >> >> However, in case someone (Thilo?) already has some idea on fixing it, >> that'd be great. > > I don't remember exactly but you will need to figure out what the actual > limit is for opt_order. > > If I could give a closer hint, this bug would have been fixed a long time > ago... > > You could have a look at the reference codec code and look where they limit > that opt_order/buffer size.
There are already patches by Michael and me which deals with this bug. Which you do not want to apply and without real proof. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
