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?
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@xiph.org > http://lists.xiph.org/mailman/listinfo/speex-dev > >
Jean-Marc Valin wrote:> 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. >gcc: Reading specs from c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/specs Configured with: ../gcc-3.4.5/configure --with-gcc --with-gnu-ld --with-gnu-as --host=mingw32 --target=mingw32 --prefix=/mingw --enable-threads --disable-nls --enable-languages=c,c++,f77,ada,objc,java --disable-win32-registry --disable-shared --enable-sjlj-exceptions --enable-libgcj --disable-java-awt --without-x --enable-java-gc=boehm --disable-libgcj-debug --enable-interpreter --enable-hash-synchronization --enable-libstdcxx-debug Thread model: win32 gcc version 3.4.5 (mingw special) Compile flags: DEFINES += NDEBUG WIN32 _WINDOWS HAVE_CONFIG_H VAR_ARRAYS VORBIS_PSYCHO CFLAGS: -O3 -march=pentium3 -mtune=pentium4 -mmmx -msse -fomit-frame-pointer -ffast-math -g -Wall SSE technically enabled in the compiler, but not used by libspeex. As for the CPU and the values of best_ntarget[j], I have no way to find out. I almost had to bully the enduser in question just to get the offset from the windows crash dialog :( .. But apparantly it crashed at that exact spot several times.