[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