[Speex-dev] Crash in cb_search.c, line 414

[Jean-Marc Valin]

That's quite strange. The only thing I can say is that the bug is most
likely *not* around line 414. It's probably some sort of memory
corruption somewhere else (quite possibly outside of Speex). Do you have
any more information? What CPU? What's the value of best_ntarget[j]? Is
SSE enabled? What's the allocation method (VAR_ARRAYS/USE_ALLOCA)? What
compiler.

	Jean-Marc

Thorvald Natvig a écrit :
> Ok, I got a strange case..
> 
> I got a bugreport from a user about my application crashing on him.
> After a bit of trouble, I got him to report back the module and offset
> it crashed at (win32). I always retain a copy of my symbol files for my
> release builds, so tracking down the crash address leads to:
> 
> (gdb) list *0x6d5c2213
> 0x6d5c2213 is in split_cb_search_shape_sign (cb_search.c:414).
> 409                 break;
> 410           }
> 411           for (j=0;j<N;j++)
> 412           {
> 413              /*previous target (we don't care what happened before*/
> 414              for (m=(i+1)*subvect_size;m<nsf;m++)
> 415                 nt[j][m]=ot[best_ntarget[j]][m];
> 416
> 417              /* New code: update the rest of the target only if it's
> worth it */
> 418              for (m=0;m<subvect_size;m++)
> 
> And the crash is at line 414. Digging through the disassembly, the crash
> seems to be the ot[best_ntarget[j]] lookup, ie: best_ntarget[j] returns
> an index that is out of bounds for ot[]. How that value gets to be
> there, I have no idea, and unfortunately I'm having trouble convincing
> the user that downloading and installing a full debugger is a good idea.
> 
> (This is against latest SVN btw)
> 
> Any ideas on what might be wrong?
> 
> _______________________________________________
> Speex-dev mailing list
> Speex-dev at xiph.org
> http://lists.xiph.org/mailman/listinfo/speex-dev
> 
>