<div dir="ltr"><div class="gmail_default" style="color:#000000">Hi,</div><div class="gmail_default" style="color:#000000"><br></div><div class="gmail_default" style="color:#000000">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.</div><div class="gmail_default" style="color:#000000"><br></div><div class="gmail_default" style="color:#000000">Here I'm attaching the captured opus encoded file which is causing the crash.</div><div class="gmail_default" style="color:#000000"><br></div><div class="gmail_default" style="color:#000000">Thanks</div><div class="gmail_default" style="color:#000000">Suresh</div><div class="gmail_default" style="color:#000000"><br></div><div class="gmail_default" style="color:#000000"><br></div><div class="gmail_default" style="color:#000000"><br></div><div class="gmail_default" style="color:#000000"><br></div><div class="gmail_default" style="color:#000000"><br></div><div class="gmail_extra"><br><div class="gmail_quote">On 17 April 2015 at 02:27, 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">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>
<span class=""><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><br>
</span><span class="">> <mailto:<a href="mailto:jmvalin@jmvalin.ca">jmvalin@jmvalin.ca</a>>> wrote:<br>
><br>
> Please provide the input file that produces this with 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 into. As I<br>
> > mentioned, I don't see the same issue in 1.1.1, but I don't see any<br>
> > difference in 1.1.1 other than optimization based on the architecture.<br>
> > This optimization could have fixed some stack overflow issue in some<br>
> > specific cases?<br>
> ><br>
> ><br>
> > Thanks<br>
> > Suresh<br>
> ><br>
> > On 13 April 2015 at 12:39, Suresh Thiriveedi <<a href="mailto:sthiriveedi@gmail.com">sthiriveedi@gmail.com</a> <mailto:<a href="mailto:sthiriveedi@gmail.com">sthiriveedi@gmail.com</a>><br>
</span><div><div class="h5">> > <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 as below.<br>
> ><br>
> > *_Backtrace we got for this crash:_*<br>
> ><br>
> > #0 0x0000000000800c54 in opus_decode_frame (st=0x38906b8f99d09c5,<br>
> ><br>
> > data=0xf0aa10b4ef1008ae <Address 0xf0aa10b4ef1008ae 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 (st=0x712357d0,<br>
> ><br>
> > data=0x7effff9ab72d<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\"\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 (st=0x712357d0,<br>
> ><br>
> > data=0x7effff9ab72d<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\"\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 src/opus_decoder.c:681<br>
> ><br>
> ><br>
> > #3 0x000000000080226c in opus_decode (st=0x712357d0,<br>
> ><br>
> > data=0x7effff9ab72c<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\"\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 (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 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 != MODE_CELT_ONLY &&<br>
> > !st->prev_redundancy)<br>
> > || (mode != MODE_CELT_ONLY && st->prev_mode == MODE_CELT_ONLY) )<br>
> > )<br>
> > {<br>
> > _transition = 1_;<br>
> > /* Decide where to allocate the stack memory for 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, IMIN(F5,<br>
> > audiosize), 0);<br>
> > }<br>
> ><br>
> > *_In "opus_decode_frame" again, as data is passed as 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 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, &st->DecControl,<br>
> > lost_flag, first_frame, &dec,<br>
> > pcm_ptr, &silk_frame_size );<br>
> ><br>
> ><br>
> > *_And finally, somehow, the "silk_frame_size" is a negative<br>
> value (<br>
> > say -1376272 in our case), then in the same function 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 <<a href="mailto:jmvalin@jmvalin.ca">jmvalin@jmvalin.ca</a> <mailto:<a href="mailto:jmvalin@jmvalin.ca">jmvalin@jmvalin.ca</a>><br>
</div></div><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>
> > Do you have any file that demonstrates the 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 stable version<br>
> > available.<br>
> > ><br>
> > > In 1.1, we are facing crash when opus library is trying to<br>
> > decode the<br>
> > > CELT-only, full band and 20 ms. So we tried with 1.1.1 beta<br>
> > and it looks<br>
> > > to be fine. Is there any open issue 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>
</span>> <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>
</blockquote></div><br></div></div>