On Mon, Mar 2, 2009 at 8:30 PM, Julian Seward <[email protected]> wrote: > >> I suggest you to try valgrind 3.4 (or 3.4.1) with a flag >> --track-origins=yes. This will give more informative reports. > > --track-origins=yes is useful for making sense of uninitialised value > errors, but not for the error shown, which is an addressing error. > >> > ==9629== Invalid read of size 4 >> > ==9629== at 0x43DE2D: >> > Pattern::sendSequence(std::_Rb_tree_iterator<std::pair<unsigned const, >> > std::string> >) (DataPattern.cpp:168) >> > ==9629== by 0x43DFC5: Pattern::bottomSearchAlgorithm() >> > (DataPattern.cpp:136) ==9629== by 0x43E011: >> > Pattern::handle(std::string const&, unsigned) (DataPattern.cpp:125) >> > : >> > : > > Look carefully at the complete error here. Does it have a second > stack trace, starting "Address xxxxx is nnn bytes before/after a block > of size mmm alloc'd at" ? If you can find that text, it will help > explain what the problem is.
There is indeed following with one stack trace, please see following error messages. It frees an object with std::map, but I failed to see why that could be a problem. I must miss something here, please enlighten me. ==9629== Address 0xaebeea8 is 32 bytes inside a block of size 48 free'd ==9629== at 0x4A05B9D: operator delete(void*) (vg_replace_malloc.c:342) ==9629== by 0x43F9A0: __gnu_cxx::new_allocator<std::_Rb_tree_node<std::pair<unsigned const, std::string> > >::deallocate(std::_Rb_tree_node<std::pair<unsigned const, std::string> >*, unsigned long) (new_allocator.h:98) ==9629== by 0x43F9C8: std::_Rb_tree<unsigned, std::pair<unsigned const, std::string>, std::_Select1st<std::pair<unsigned const, std::string> >, std::less<unsigned>, std::allocator<std::pair<unsigned const, std::string> > >::_M_put_node(std::_Rb_tree_node<std::pair<unsigned const, std::string> >*) (stl_tree.h:361) ==9629== by 0x43FA15: std::_Rb_tree<unsigned, std::pair<unsigned const, std::string>, std::_Select1st<std::pair<unsigned const, std::string> >, std::less<unsigned>, std::allocator<std::pair<unsigned const, std::string> > >::_M_destroy_node(std::_Rb_tree_node<std::pair<unsigned const, std::string> >*) (stl_tree.h:391) ==9629== by 0x43FA75: std::_Rb_tree<unsigned, std::pair<unsigned const, std::string>, std::_Select1st<std::pair<unsigned const, std::string> >, std::less<unsigned>, std::allocator<std::pair<unsigned const, std::string> > >::erase(std::_Rb_tree_iterator<std::pair<unsigned const, std::string> >) (stl_tree.h:1319) ==9629== by 0x43FAA8: std::map<unsigned, std::string, std::less<unsigned>, std::allocator<std::pair<unsigned const, std::string> > >::erase(std::_Rb_tree_iterator<std::pair<unsigned const, std::string> >) (stl_map.h:523) I'll take your advice to try valgrind 3.4 (or 3.4.1) with a flag --track-origins=yes. But I am more worried about the memory problems as Julian indicated. Thank you. Geny ------------------------------------------------------------------------------ Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H _______________________________________________ Valgrind-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/valgrind-users
