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