[Clam-devel] segfault in ChordExtractor

Roman Goj roman.goj at gmail.com
Sat Aug 18 14:54:28 PDT 2007


hi!

I've got an interesting non deterministic segfault :)

I run ./ChordExtractor pitch100.wav

and get a segfault at the finish with a bt in gdb:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1263769888 (LWP 6785)]
0x0806bda9 in CLAM::Array<float>::InitializeCopyDataBlock
(this=0x80d0c50, first=0, last=12,
    src=0x1099) at
/home/romcio/Projects/GSoC/local/include/CLAM/Array.hxx:460
460                     new(&mpData[i]) T(src[i]);
(gdb) bt
#0  0x0806bda9 in CLAM::Array<float>::InitializeCopyDataBlock
(this=0x80d0c50, first=0, last=12,
    src=0x1099) at
/home/romcio/Projects/GSoC/local/include/CLAM/Array.hxx:460
#1  0x08088619 in CLAM::Array<float>::ResizeDataBuffer (this=0x80d0c50,
new_size=12)
    at /home/romcio/Projects/GSoC/local/include/CLAM/Array.hxx:495
#2  0x0808874d in CLAM::Array<float>::Resize (this=0x80d0c50,
newAllocSize=12)
    at /home/romcio/Projects/GSoC/local/include/CLAM/Array.hxx:132
#3  0x0808b47f in ChordExtractorDescriptionDumper::doIt (this=0xbf8a4a58)
    at src/ChordExtractor/MainClam.cxx:296
#4  0x08067fc5 in main (argc=2, argv=0xbf8a50a4) at
src/ChordExtractor/MainClam.cxx:500


the line in MainClam.cxx is:
_pcps[_currentFrame].Resize(pcp.size());


this line probably has nothing to do with it, there's a new operator
involved in resizing. We agreed with David, that it's probably some left
over memory from some other parts of the code, valgrind shows this, when
I run

valgrind ./ChordExtractor pitch100.wav:

==7492== Invalid write of size 8
==7492==    at 0x463E951: void
FourierTransform::doItGeneric<float>(float const*)
(FourierTransform.cxx:144)
==7492==    by 0x463DED3: FourierTransform::doIt(float const*)
(FourierTransform.cxx:168)
==7492==    by 0x808AD0B: Simac::ChordExtractor::doIt(float* const&,
float&) (ChordExtractor.hxx:106)
==7492==    by 0x8067F9E: main (MainClam.cxx:496)
==7492==  Address 0x7643028 is 0 bytes after a block of size 524,288 alloc'd
==7492==    at 0x4023C55: operator new(unsigned) (vg_replace_malloc.c:163)
==7492==    by 0x8070C4F:
__gnu_cxx::new_allocator<double>::allocate(unsigned, void const*)
(new_allocator.h:88)
==7492==    by 0x8070C73: std::_Vector_base<double,
std::allocator<double> >::_M_allocate(unsigned) (stl_vector.h:127)
==7492==    by 0x807CB53: std::vector<double, std::allocator<double>
>::_M_fill_insert(__gnu_cxx::__normal_iterator<double*,
std::vector<double, std::allocator<double> > >, unsigned, double const&)
(vector.tcc:357)
==7492==    by 0x807CD81: std::vector<double, std::allocator<double>
>::insert(__gnu_cxx::__normal_iterator<double*, std::vector<double,
std::allocator<double> > >, unsigned, double const&) (stl_vector.h:658)
==7492==    by 0x807CE6C: std::vector<double, std::allocator<double>
>::resize(unsigned, double) (stl_vector.h:426)
==7492==    by 0x463E32A: FourierTransform::FourierTransform(unsigned
long, double, bool) (FourierTransform.cxx:35)
==7492==    by 0x808048C:
Simac::ChordExtractor::ChordExtractor(unsigned, unsigned, double,
unsigned) (ChordExtractor.hxx:78)
==7492==    by 0x8067BA5: main (MainClam.cxx:467)


also - the file (attached) ran through valgrind... does not produce a
crash... also most of the files I try run perfectly fine through
ChordExtractor, no crashes... no idea why this file causes a segfault :(

trying to fix this... but I'm not very optimistic about the results of
my coming endavours... so if anyone has any tips, they'd be appreciated :)

cheers,
roman




More information about the clam-devel mailing list