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> 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>> 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>>> 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>>>> 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>>>>> > 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>>>>> 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>>>> > > > > > > http://lists.xiph.org/mailman/listinfo/opus > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >-------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.xiph.org/pipermail/opus/attachments/20150421/b4d38a8a/attachment-0001.htm
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> 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> 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>> 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>>> 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>>>> 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>>>>> >> 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>>>>> 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>>>> >> > > > > > http://lists.xiph.org/mailman/listinfo/opus >> > > > > > >> > > > > >> > > > > >> > > > > >> > > > >> > > > >> > > >> > > >> > >> > >> > >-------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.xiph.org/pipermail/opus/attachments/20150422/0f20ff2a/attachment-0001.htm
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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
Hi Suresh, What input file are you using that is triggering the crash in opus_demo? Does the crash occur using opus_demo with an unmodified libopus? (It appears that your version has been modified to print some debug information.) - Mark