[opus] Availability of the 1.1.1 stable version
Jean-Marc Valin
jmvalin at jmvalin.ca
Wed Apr 22 08:28:09 PDT 2015
On my machine, I have:
Fedora 20 (64-bit)
gcc version 4.8.3 20140911 (Red Hat 4.8.3-7) (GCC)
I build as
./configure --disable-shared
make
and I don't see any crash.
On 22/04/15 07:37 AM, Suresh Thiriveedi wrote:
> Hi
>
> Looks like 1.1 version is sensitive to the system
> architecture/compiler/kernel version. Below is my observation in various
> linux system I have.
>
> As you mentioned, you are not observed the crash in your system, can you
> please share your system details. And also please comment on the below
> table/observations.
>
>
>
> *Machine IP*
>
>
>
> *optimization flags*
>
>
>
> *RHEL version*
>
>
>
> *kernel version*
>
>
>
> *gcc version*
>
>
>
> *architecture*
>
>
>
> *Result/observation*
>
> 172.27.2.63
>
>
>
> CFLAGS = -g -O0
>
>
>
> 6.4
>
>
>
> 2.6.32-358.18.1.el6.x86_64
>
>
>
> 4.4.7
>
>
>
> Intel(R) Xeon(R) CPU E5-2648L 0 @ 1.80GHz
>
>
>
> Crash
>
> 172.27.9.56
>
>
>
> CFLAGS = -g -O0
>
>
>
> 7
>
>
>
> 3.10.0-123.13.1.el7.x86_64
>
>
>
> 4.8.2
>
>
>
> Intel(R) Xeon(R) CPU E5-2650 0 @ 2.00GHz
>
>
>
> No Crash
>
> 172.27.5.231
>
>
>
> CFLAGS = -g -O0
>
>
>
> 5.3
>
>
>
> 2.6.18-128.el5
>
>
>
> 4.1.2
>
>
>
> Intel(R) Core(TM) i3 CPU 540 @ 3.07GHz
>
>
>
> No Crash
>
> With any other optimization flags (1,2,3), it is crashing in all the
> above servers.
>
>
>
> Thanks
> Suresh
>
>
>
>
>
> On 21 April 2015 at 14:17, Suresh Thiriveedi <sthiriveedi at gmail.com
> <mailto:sthiriveedi at gmail.com>> wrote:
>
>
> Red Hat Enterprise Linux Server release 6.4 (Santiago)
> gcc version 4.4.7 20120313 (Red Hat 4.4.7-3) (GCC)
>
> We see the issue in all our Intel based Linux servers.
>
> Thanks
> Suresh
>
>
>
> On 21 April 2015 at 12:41, Jean-Marc Valin <jmvalin at jmvalin.ca
> <mailto:jmvalin at jmvalin.ca>> wrote:
>
> Still can't reproduce. What OS and compiler version?
>
> Jean-Marc
>
> On 21/04/15 02:48 AM, Suresh Thiriveedi wrote:
> > Hi,
> >
> > There is no change in the compiler flags. I'm using as it is from the
> > original code. No change in the Makefile and I believe it is using the
> > floating point only by default.
> >
> > We are using 8k samples and mono so the commands is as follows.
> >
> > [root at MEDIA opus-1.1]# ./opus_demo -d 8000 1 opus_encoded_crash.opus
> > opus_encoded_crash.pcm
> >
> > *_And segmentation is as below.._*.
> > ............
> > Calling opus_decode123. len[toggle]:79, output_samples:96000
> > data[0] = 78
> > data[0] = 78
> > 78 87 46 18 4f fe a6 be 7d 8 6 33 e2 79 ee e4 71 55 a7 3a 8 c9 48 d6
> > a7 20 3b 7 95 18 b8 4b 8f 24 fa a6 50 87 97 9c d7 13 d0 b2 c3 c4 6d 2f
> > 8b 6c 13 6f bb 16 cc 20 85 4e c7 5d 2e 90 41 ae 47 8b 3e 36 eb c7 c8 28
> > 94 3 c3 f9 52 aa 84 output_samples ==<160>
> > Calling opus_decode123. len[toggle]:89, output_samples:96000
> > data[0] = 78
> > data[0] = 78
> > 78 87 29 db 92 15 9c 94 bf b8 cd 23 22 ab bf bf 48 26 52 21 26 b5 b2 d5
> > 4d 7c 6f 8f ec 65 d2 2c 2 30 7f 81 dc 4 9c 10 82 5f e7 ff 62 4e ec d4
> > ac 16 9a 4d a9 49 67 86 e7 c a8 6c a5 4f 45 2f 95 b0 71 32 fb b6 fb 72
> > fd 25 f5 40 65 df 4e 5d 8c 2d 84 8e 17 c6 67 12 5f output_samples ==<160>
> > Calling opus_decode123. len[toggle]:3, output_samples:96000
> > *data[0] = f8*
> > *data[0] = f8*
> > *Segmentation fault*
> > [root at MEDIA opus-1.1]#
> >
> > Whereas if I run the same in 1.1.1, this is the output and i'm able to
> > play the pcm file
> >
> > [root at MEDIA opus-1.1]#./opus_demo -d 8000 1 opus_encoded_crash.opus
> > opus_encoded_crash.pcm
> > libopus 1.1.1-beta
> > Decoding with 8000 Hz output (1 channels)
> > average bitrate: 31.864 kb/s
> > maximum bitrate: 49.200 kb/s
> > bitrate standard deviation: 3.412 kb/s
> > [root at MEDIA opus-1.1]#
> >
> > *_compiler flags in 1.1:_*
> >
> > AWK = gawk
> > CC = gcc -std=gnu99
> > CCAS = gcc -std=gnu99
> > CCASDEPMODE = depmode=gcc3
> > CCASFLAGS = -g -O2
> > CCDEPMODE = depmode=gcc3
> > CFLAGS = -g -O2 -fvisibility=hidden -W -Wall -Wextra -Wcast-align
> > -Wnested-externs -Wshadow -Wstrict-prototypes
> > CPP = gcc -E
> > CPPFLAGS =
> > CYGPATH_W = echo
> > DEFS = -DHAVE_CONFIG_H
> > DEPDIR = .deps
> > DLLTOOL = false
> >
> >
> > But If i run the same command you did (./opus_demo -d 48000 2
> > opus_encoded_crash.opus out.pcm) also crashed (same). Do I need to
> > change any Makefile setting based on my system configuration? What is
> > your system config?
> >
> > *This is my system config:*
> > model name :*Intel(R) *Core(TM) i3 CPU 540 @ 3.07GHz
> >
> >
> > Thanks
> > Suresh
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > On 21 April 2015 at 07:45, Jean-Marc Valin <jmvalin at jmvalin.ca <mailto:jmvalin at jmvalin.ca>
> > <mailto:jmvalin at jmvalin.ca <mailto:jmvalin at jmvalin.ca>>> wrote:
> >
> > I just tried decoding with v1.1:
> > ./opus_demo -d 48000 2 opus_encoded_crash.opus out.pcm
> >
> > and I see no issue (including with valgrind). Does the same command-line
> > create problems for you? What compile flags did you use? fixed-point or
> > float, any assembly, ...? Could be assembly here, or even a compiler bug
> > wouldn't be unheard of.
> >
> > Cheers,
> >
> > Jean-Marc
> >
> >
> > On 20/04/15 07:27 AM, Suresh Thiriveedi wrote:
> > > Hi,
> > >
> > > We are able to reproduce the issue with the 1.1 opus_demo (sample file).
> > > We captured the frames in our server just before the opus_decode and fed
> > > the file to opus_demo (1.1) and it is crashing. Same file is tested with
> > > 1.1.1 and it is fine. So this is in line with our server testing
> > > observation and I think here we can conclude that the 1.1 library is
> > > crashing while handling a specific mode frame as explained in my earlier
> > > mail.
> > >
> > > Here I'm attaching the captured opus encoded file which is causing the
> > > crash.
> > >
> > > Thanks
> > > Suresh
> > >
> > >
> > >
> > >
> > >
> > >
> > > On 17 April 2015 at 02:27, Jean-Marc Valin <jmvalin at jmvalin.ca <mailto:jmvalin at jmvalin.ca>
> <mailto:jmvalin at jmvalin.ca <mailto:jmvalin at jmvalin.ca>>
> > > <mailto:jmvalin at jmvalin.ca <mailto:jmvalin at jmvalin.ca>
> <mailto:jmvalin at jmvalin.ca <mailto:jmvalin at jmvalin.ca>>>> wrote:
> > >
> > > To be decodable by opus_demo, you'll have to add the 8-byte "header".
> > > Just put in the length of the packet followed by "0" for the encoder
> > > range (0 means "not present").
> > >
> > > That being said, from previous experience, the most likely cause of the
> > > crash is a bug in your software causing a corruption in Opus. So it's
> > > safe to assume that if you can't reproduce the bug using opus_demo, then
> > > that's indeed the case.
> > >
> > > Cheers,
> > >
> > > Jean-Marc
> > >
> > > On 16/04/15 08:32 AM, Suresh Thiriveedi wrote:
> > > > This is observed on a live call between webRTC browser client and
> > > > another legacy client. Our server is there in between and transcoding
> > > > from opus to another codec and this is observed while decoding the opus.
> > > >
> > > > Anyway, I'll try to capture/dump the packets in the server before
> > > > feeding to the opus_decode and share with you. But this will not have
> > > > the first 8 bytes (length+enc range) to directly feed to the sample
> > > > binary. Please let me know if this is fine.
> > > >
> > > > Thanks
> > > > Suresh
> > > >
> > > > On 16 April 2015 at 17:36, Jean-Marc Valin <jmvalin at jmvalin.ca <mailto:jmvalin at jmvalin.ca>
> <mailto:jmvalin at jmvalin.ca <mailto:jmvalin at jmvalin.ca>>
> > <mailto:jmvalin at jmvalin.ca <mailto:jmvalin at jmvalin.ca>
> <mailto:jmvalin at jmvalin.ca <mailto:jmvalin at jmvalin.ca>>>
> > > > <mailto:jmvalin at jmvalin.ca <mailto:jmvalin at jmvalin.ca>
> <mailto:jmvalin at jmvalin.ca <mailto:jmvalin at jmvalin.ca>>
> > <mailto:jmvalin at jmvalin.ca <mailto:jmvalin at jmvalin.ca>
> <mailto:jmvalin at jmvalin.ca <mailto:jmvalin at jmvalin.ca>>>>> wrote:
> > > >
> > > > Please provide the input file that produces
> this with
> > opus_demo.
> > > >
> > > > On 16/04/15 03:24 AM, Suresh Thiriveedi wrote:
> > > > > Hi Jean-Marc,
> > > > >
> > > > > Could you please update if you got a chance
> to look
> > into. As I
> > > > > mentioned, I don't see the same issue in
> 1.1.1, but I
> > don't see any
> > > > > difference in 1.1.1 other than optimization
> based on
> > the architecture.
> > > > > This optimization could have fixed some
> stack overflow
> > issue in some
> > > > > specific cases?
> > > > >
> > > > >
> > > > > Thanks
> > > > > Suresh
> > > > >
> > > > > On 13 April 2015 at 12:39, Suresh Thiriveedi
> > <sthiriveedi at gmail.com <mailto:sthiriveedi at gmail.com>
> <mailto:sthiriveedi at gmail.com <mailto:sthiriveedi at gmail.com>>
> > <mailto:sthiriveedi at gmail.com
> <mailto:sthiriveedi at gmail.com> <mailto:sthiriveedi at gmail.com
> <mailto:sthiriveedi at gmail.com>>>
> > > <mailto:sthiriveedi at gmail.com
> <mailto:sthiriveedi at gmail.com> <mailto:sthiriveedi at gmail.com
> <mailto:sthiriveedi at gmail.com>>
> > <mailto:sthiriveedi at gmail.com
> <mailto:sthiriveedi at gmail.com> <mailto:sthiriveedi at gmail.com
> <mailto:sthiriveedi at gmail.com>>>>
> > > > > <mailto:sthiriveedi at gmail.com
> <mailto:sthiriveedi at gmail.com>
> > <mailto:sthiriveedi at gmail.com
> <mailto:sthiriveedi at gmail.com>> <mailto:sthiriveedi at gmail.com
> <mailto:sthiriveedi at gmail.com>
> > <mailto:sthiriveedi at gmail.com <mailto:sthiriveedi at gmail.com>>>
> > > <mailto:sthiriveedi at gmail.com
> <mailto:sthiriveedi at gmail.com> <mailto:sthiriveedi at gmail.com
> <mailto:sthiriveedi at gmail.com>>
> > <mailto:sthiriveedi at gmail.com
> <mailto:sthiriveedi at gmail.com> <mailto:sthiriveedi at gmail.com
> <mailto:sthiriveedi at gmail.com>>>>>> wrote:
> > > > >
> > > > > Hi Jean-Marc,
> > > > >
> > > > > Thanks for your response. Please find
> the details
> > as below.
> > > > >
> > > > > *_Backtrace we got for this crash:_*
> > > > >
> > > > > #0 0x0000000000800c54 in opus_decode_frame
> > > (st=0x38906b8f99d09c5,
> > > > >
> > > > > data=0xf0aa10b4ef1008ae <Address
> > 0xf0aa10b4ef1008ae
> > > out of
> > > > > bounds>, len=-188613428,
> pcm=0x6e80016085efd57,
> > > > >
> > > > > frame_size=44037315,
> decode_fec=58716895) at
> > > > src/opus_decoder.c:384
> > > > >
> > > > >
> > > > > #1 0x00000000008009c0 in opus_decode_frame
> > (st=0x712357d0,
> > > > >
> > > > > data=0x7effff9ab72d
> > > > >
> > > >
> > >
> >
> "~▒`\\▒K\005▒▒y▒w+g~▒S2\025▒\036T▒\002x▒▒h!▒▒▒\220\233\066s▒\030#gb
> > > > > \rn▒rF\005Q▒\213;▒`\207$O▒(m
> \222=9▒▒/h▒▒t▒▒E묳w▒\237\"
> > > \206z\005
> > > > > \213»u at e", len=88, pcm=0x7effff9a6a80,
> frame_size=640,
> > > > decode_fec=0)
> > > > > at src/opus_decoder.c:319
> > > > >
> > > > >
> > > > > #2 0x0000000000801be1 in opus_decode_native
> > (st=0x712357d0,
> > > > >
> > > > > data=0x7effff9ab72d
> > > > >
> > > >
> > >
> >
> "~▒`\\▒K\005▒▒y▒w+g~▒S2\025▒\036T▒\002x▒▒h!▒▒▒\220\233\066s▒\030#gb
> > > > > \rn▒rF\005Q▒\213;▒`\207$O▒(m
> \222=9▒▒/h▒▒t▒▒E묳w▒\237\"
> > > \206z\005
> > > > > \213»u at e", len=89, pcm=0x7effff9a6a80,
> frame_size=640,
> > > > decode_fec=0,
> > > > > self_delimited=0,
> > > > >
> > > > > packet_offset=0x0, soft_clip=1) at
> > > src/opus_decoder.c:681
> > > > >
> > > > >
> > > > > #3 0x000000000080226c in opus_decode
> (st=0x712357d0,
> > > > >
> > > > > data=0x7effff9ab72c
> > > > >
> > > >
> > >
> >
> "▒~▒`\\▒K\005▒▒y▒w+g~▒S2\025▒\036T▒\002x▒▒h!▒▒▒\220\233\066s▒\030#gb
> > > > > \rn▒rF\005Q▒\213;▒`\207$O▒(m
> \222=9▒▒/h▒▒t▒▒E묳w▒\237\"
> > > \206z\005
> > > > > \213»u at e", len=89, pcm=0x71245a60,
> frame_size=640,
> > > > decode_fec=0) at
> > > > > src/opus_decoder.c:867
> > > > >
> > > > >
> > > > > #4 0x00000000004fd6b5 in kn_opus_decode
> > > (decHandle=0x712357d0,
> > > > > decProp=0x1675698, src=0x16756d0,
> dest=0x71245a60,
> > > > >
> > > > > dstLen=0x1673210) at
> MSTranscodeOPUS.c:100
> > > > >
> > > > >
> > > > >
> > > > > *_And the code flow what we have
> observed for this
> > specific
> > > > incident:_*
> > > > > *_
> > > > > _*
> > > > > *_Called this as mode is CELT_ONLY,_*
> > > > >
> > > > > if (data!=NULL && st->prev_mode > 0 && (
> > > > > (mode == MODE_CELT_ONLY &&
> st->prev_mode !=
> > > MODE_CELT_ONLY &&
> > > > > !st->prev_redundancy)
> > > > > || (mode != MODE_CELT_ONLY &&
> st->prev_mode ==
> > > MODE_CELT_ONLY) )
> > > > > )
> > > > > {
> > > > > _transition = 1_;
> > > > > /* Decide where to allocate the
> stack memory for
> > > pcm_transition */
> > > > > if (mode == MODE_CELT_ONLY)
> > > > > pcm_transition_celt_size =
> F5*st->channels;
> > > > > else
> > > > > pcm_transition_silk_size =
> F5*st->channels;
> > > > > }
> > > > >
> > > > > *_So transition is made as 1 called this,_*
> > > > >
> > > > > if (transition && mode == MODE_CELT_ONLY)
> > > > > {
> > > > > pcm_transition = pcm_transition_celt;
> > > > > opus_decode_frame(st, NULL, 0,
> pcm_transition,
> > > IMIN(F5,
> > > > > audiosize), 0);
> > > > > }
> > > > >
> > > > > *_In "opus_decode_frame" again, as data
> is passed as
> > > NULL, goes to
> > > > > else part_*
> > > > >
> > > > > if (data != NULL)
> > > > > {
> > > > > audiosize = st->frame_size;
> > > > > mode = st->mode;
> > > > > ec_dec_init(&dec,(unsigned
> char*)data,len);
> > > > > } else {
> > > > > audiosize = frame_size;
> > > > > mode = st->prev_mode;
> > > > >
> > > > > *_As the mode is made as prev mode now,
> which was a
> > > silk, this
> > > > goes
> > > > > inside,_*
> > > > >
> > > > > /* SILK processing */
> > > > > if (mode != MODE_CELT_ONLY)
> > > > > {
> > > > >
> > > > > *_Then in this function called this_*,
> > > > >
> > > > > silk_ret = silk_Decode( silk_dec,
> > &st->DecControl,
> > > > > lost_flag,
> > first_frame,
> > > &dec,
> > > > > pcm_ptr, &silk_frame_size );
> > > > >
> > > > >
> > > > > *_And finally, somehow, the
> "silk_frame_size" is a
> > negative
> > > > value (
> > > > > say -1376272 in our case), then in the
> same function
> > > called the
> > > > > below and this crashes here._*
> > > > >
> > > > > pcm_ptr += silk_frame_size * st->channels;
> > > > >
> > > > >
> > > > > Please help.
> > > > >
> > > > > Thanks
> > > > > Suresh
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > On 12 April 2015 at 21:23, Jean-Marc Valin
> > > <jmvalin at jmvalin.ca <mailto:jmvalin at jmvalin.ca>
> <mailto:jmvalin at jmvalin.ca <mailto:jmvalin at jmvalin.ca>>
> > <mailto:jmvalin at jmvalin.ca <mailto:jmvalin at jmvalin.ca>
> <mailto:jmvalin at jmvalin.ca <mailto:jmvalin at jmvalin.ca>>>
> > > <mailto:jmvalin at jmvalin.ca
> <mailto:jmvalin at jmvalin.ca> <mailto:jmvalin at jmvalin.ca
> <mailto:jmvalin at jmvalin.ca>>
> > <mailto:jmvalin at jmvalin.ca <mailto:jmvalin at jmvalin.ca>
> <mailto:jmvalin at jmvalin.ca <mailto:jmvalin at jmvalin.ca>>>>
> > > > > <mailto:jmvalin at jmvalin.ca
> <mailto:jmvalin at jmvalin.ca>
> > <mailto:jmvalin at jmvalin.ca <mailto:jmvalin at jmvalin.ca>>
> <mailto:jmvalin at jmvalin.ca <mailto:jmvalin at jmvalin.ca>
> > <mailto:jmvalin at jmvalin.ca <mailto:jmvalin at jmvalin.ca>>>
> > > <mailto:jmvalin at jmvalin.ca
> <mailto:jmvalin at jmvalin.ca> <mailto:jmvalin at jmvalin.ca
> <mailto:jmvalin at jmvalin.ca>>
> > <mailto:jmvalin at jmvalin.ca <mailto:jmvalin at jmvalin.ca>
> <mailto:jmvalin at jmvalin.ca <mailto:jmvalin at jmvalin.ca>>>>>> wrote:
> > > > >
> > > > > Do you have any file that
> demonstrates the
> > problem with either
> > > > > opus_demo
> > > > > or opusdec?
> > > > >
> > > > > Jean-Marc
> > > > >
> > > > > On 09/04/15 04:01 AM, Suresh
> Thiriveedi wrote:
> > > > > > Hi,
> > > > > >
> > > > > > I'm curious to know when would be
> the 1.1.1
> > stable version
> > > > > available.
> > > > > >
> > > > > > In 1.1, we are facing crash when opus
> > library is trying to
> > > > > decode the
> > > > > > CELT-only, full band and 20 ms. So
> we tried
> > with 1.1.1 beta
> > > > > and it looks
> > > > > > to be fine. Is there any open issue
> > regarding this in 1.1 version?
> > > > > >
> > > > > > Thanks
> > > > > > Suresh
> > > > > >
> > > > > >
> > > > > >
> _______________________________________________
> > > > > > opus mailing list
> > > > > > opus at xiph.org
> <mailto:opus at xiph.org> <mailto:opus at xiph.org <mailto:opus at xiph.org>>
> > <mailto:opus at xiph.org <mailto:opus at xiph.org>
> <mailto:opus at xiph.org <mailto:opus at xiph.org>>>
> <mailto:opus at xiph.org <mailto:opus at xiph.org>
> > <mailto:opus at xiph.org <mailto:opus at xiph.org>>
> > > <mailto:opus at xiph.org <mailto:opus at xiph.org>
> <mailto:opus at xiph.org <mailto:opus at xiph.org>>>>
> > > > <mailto:opus at xiph.org <mailto:opus at xiph.org>
> <mailto:opus at xiph.org <mailto:opus at xiph.org>>
> > <mailto:opus at xiph.org <mailto:opus at xiph.org>
> <mailto:opus at xiph.org <mailto:opus at xiph.org>>>
> > > <mailto:opus at xiph.org <mailto:opus at xiph.org>
> <mailto:opus at xiph.org <mailto:opus at xiph.org>>
> > <mailto:opus at xiph.org <mailto:opus at xiph.org>
> <mailto:opus at xiph.org <mailto:opus at xiph.org>>>>>
> > > > > >
> http://lists.xiph.org/mailman/listinfo/opus
> > > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>
>
More information about the opus
mailing list