<div dir="ltr"><div class="gmail_default" style="color:rgb(0,0,0)">Hi,</div><div class="gmail_default" style="color:rgb(0,0,0)"><br></div><div class="gmail_default" style="color:rgb(0,0,0)">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. </div><div class="gmail_default" style="color:rgb(0,0,0)"><br></div><div class="gmail_default" style="color:rgb(0,0,0)">We are using 8k samples and mono so the commands is as follows.</div><div class="gmail_default" style="color:rgb(0,0,0)"><br></div><div class="gmail_default" style><font color="#000000">[root@MEDIA opus-1.1]# ./opus_demo -d 8000 1 opus_encoded_crash.opus opus_encoded_crash.pcm</font><br></div><div class="gmail_default" style><font color="#000000"><br></font></div><div class="gmail_default" style><font color="#000000"><b><u>And segmentation is as below..</u></b>.</font></div><div class="gmail_default" style><font color="#000000">............</font></div><div class="gmail_default" style><font color="#000000"><div class="gmail_default"><div class="gmail_default">Calling opus_decode123. len[toggle]:79, output_samples:96000</div><div class="gmail_default">data[0] = 78</div><div class="gmail_default">data[0] = 78</div><div class="gmail_default">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></div><div class="gmail_default">Calling opus_decode123. len[toggle]:89, output_samples:96000</div><div class="gmail_default">data[0] = 78</div><div class="gmail_default">data[0] = 78</div><div class="gmail_default">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></div><div class="gmail_default">Calling opus_decode123. len[toggle]:3, output_samples:96000</div><div class="gmail_default"><b>data[0] = f8</b></div><div class="gmail_default"><b>data[0] = f8</b></div><div class="gmail_default"><b>Segmentation fault</b></div><div>[root@MEDIA opus-1.1]#<br></div><div><br></div><div>Whereas if I run the same in 1.1.1, this is the output and i'm able to play the pcm file</div><div><br></div><div>[root@MEDIA opus-1.1]#./opus_demo -d 8000 1 opus_encoded_crash.opus opus_encoded_crash.pcm<br></div><div><div>libopus 1.1.1-beta</div><div>Decoding with 8000 Hz output (1 channels)</div><div>average bitrate: 31.864 kb/s</div><div>maximum bitrate: 49.200 kb/s</div><div>bitrate standard deviation: 3.412 kb/s</div></div><div>[root@MEDIA opus-1.1]#<br></div><div><br></div><div><b><u>compiler flags in 1.1:</u></b><br></div></div><div class="gmail_default"><br></div><div class="gmail_default"><div class="gmail_default">AWK = gawk</div><div class="gmail_default">CC = gcc -std=gnu99</div><div class="gmail_default">CCAS = gcc -std=gnu99</div><div class="gmail_default">CCASDEPMODE = depmode=gcc3</div><div class="gmail_default">CCASFLAGS = -g -O2</div><div class="gmail_default">CCDEPMODE = depmode=gcc3</div><div class="gmail_default">CFLAGS = -g -O2 -fvisibility=hidden -W -Wall -Wextra -Wcast-align -Wnested-externs -Wshadow -Wstrict-prototypes</div><div class="gmail_default">CPP = gcc -E</div><div class="gmail_default">CPPFLAGS =</div><div class="gmail_default">CYGPATH_W = echo</div><div class="gmail_default">DEFS = -DHAVE_CONFIG_H</div><div class="gmail_default">DEPDIR = .deps</div><div class="gmail_default">DLLTOOL = false</div><div><br></div><div><br></div><div>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?<br></div><div><br></div><div><b>This is my system config:</b></div><div>model name :<b> Intel(R) </b>Core(TM) i3 CPU 540 @ 3.07GHz<br></div><div><br></div><div><br></div><div>Thanks</div><div>Suresh</div></div><div><br></div></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 class="gmail_default" style><font color="#000000"><br></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 class="gmail_default" style="color:rgb(0,0,0)"><br></div><div class="gmail_default" style="color:rgb(0,0,0)"><br></div><div class="gmail_default" style="color:rgb(0,0,0)"><br></div><div class="gmail_default" style="color:rgb(0,0,0)"><br></div><div class="gmail_default" style="color:rgb(0,0,0)"><br></div><div class="gmail_default" style="color:rgb(0,0,0)"><br></div><div class="gmail_default" style="color:rgb(0,0,0)"><br></div><div class="gmail_default" style="color:rgb(0,0,0)"><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 21 April 2015 at 07:45, 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">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>
<span class=""><br>
<br>
On 20/04/15 07:27 AM, Suresh Thiriveedi wrote:<br>
> Hi,<br>
><br>
</span><span class="">> 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><br>
</span><span class="">> <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>
</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>
</span><div><div class="h5">> > 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>
> <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>>>>> 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<br>
> (st=0x38906b8f99d09c5,<br>
> > ><br>
> > > data=0xf0aa10b4ef1008ae <Address 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 (st=0x712357d0,<br>
> > ><br>
> > > data=0x7effff9ab72d<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 (st=0x712357d0,<br>
> > ><br>
> > > data=0x7effff9ab72d<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>
> "▒~▒`\\▒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 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, &st->DecControl,<br>
> > > lost_flag, first_frame,<br>
> &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<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>>>>> 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>> <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>
</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>
</blockquote></div><br></div>