Re: [ptr_container] memory corruption in ptr_set test

On 5/12/05, Thorsten Ottosen <nesotto@cs.aau.dk> wrote:
I can't easily deduce what the error should be from that file. Unfortunately I don't have any of the failing compilers.
Could the problem be related to dynamic cast and not enabling RTTI in the compiler?
No, thats definitely not it. Gcc enables RTTI by default. It looks to me like this call is the problem (for the instantiation of ptr_set_test< ptr_set<Base>, Base, Derived_class >): associative_test_data.hpp:108 i = c.find( *t ); According to valgrind, the memory location pointed to by t was previously deleted. Indeed, I added some debugging output to the Base class ctor and dtor methods, and this is what is happening: Running 1 test case... Base::Base @ 0x1bb45770 Derived_class @ 0x1bb45770 Base::Base @ 0x1bb45c58 Derived_class @ 0x1bb45c58 Base::Base @ 0x1bb46140 Derived_class @ 0x1bb46140 Base::Base @ 0x1bb46628 Derived_class @ 0x1bb46628 Base::~Base @ 0x1bb45c58 Base::~Base @ 0x1bb46140 Base::~Base @ 0x1bb46628 Base::~Base @ 0x1bb45770 Base::Base @ 0x1bb47d90 Derived_class @ 0x1bb47d90 Base::Base @ 0x1bb48798 Derived_class @ 0x1bb48798 Base::Base @ 0x1bb48c80 Derived_class @ 0x1bb48c80 ==15713== Invalid read of size 4 [...] ==15713== Address 0x1BB45770 is 0 bytes inside a block of size 24 free'd ==15713== at 0x1B904CA8: operator delete(void*) (vg_replace_malloc.c:155) ==15713== by 0x8062A4E: Derived_class::~Derived_class() (result_iterator.hpp:59) ==15713== by 0x8063A43: void boost::checked_delete<Base const>(Base const*) (checked_delete.hpp:34) ==15713== by 0x8063A22: void boost::delete_clone<Base>(Base const*) (clone_allocator.hpp:32) ==15713== by 0x8063A0E: void boost::heap_clone_allocator::deallocate_clone<Base>(Base const*) (clone_allocator.hpp:50) ==15713== by 0x80639FA: boost::ptr_container_detail::reversible_ptr_container<boost::ptr_container_detail::set_config<Base, std::set<void*, boost::void_ptr_indirect_fun<std::less<Base>, Base, Base>, std::allocator<void*> > >, boost::heap_clone_allocator>::null_clone_allocator<false>::deallocate_clone(Base const*) (reversible_ptr_container.hpp:112) The address 0x1BB45770 corresponds to the first Base object, which comes from "t = new T" on line 56 of associative_test_data.hpp. This operation seems to be causing it to be deleted: associative_test_data.hpp:66 c3.clear();
Running 1 test case... unknown location(0): fatal error in "test_set": std::bad_typeid: Access violation - no RTTI data!
^^^^^^^^^^
or is the compiler trying to say that it has seen a null pointer ("location(0)") ?
I assume it is due to the runtime zeroing out memory after it is freed, so the vtable of this object is overwritten. -- Caleb Epstein caleb dot epstein at gmail dot com

On Thu, May 12, 2005 at 09:39:27PM -0400, Caleb Epstein wrote:
I assume it is due to the runtime zeroing out memory after it is freed, so the vtable of this object is overwritten.
This sounds like what I've been seeing with GCC 4 for some time: http://lists.boost.org/boost/2005/05/26098.php I don't yet know if this is a GCC4 miscompilation bug or something wrong in the library or the tests. jon -- Always forgive your enemies; nothing annoys them so much. - Oscar Wilde

"Jonathan Wakely" <cow@compsoc.man.ac.uk> wrote in message news:20050513094305.GA29478@compsoc.man.ac.uk... | On Thu, May 12, 2005 at 09:39:27PM -0400, Caleb Epstein wrote: | | > I assume it is due to the runtime zeroing out memory after it is | > freed, so the vtable of this object is overwritten. | | This sounds like what I've been seeing with GCC 4 for some time: | | http://lists.boost.org/boost/2005/05/26098.php | | I don't yet know if this is a GCC4 miscompilation bug or something wrong | in the library or the tests. there was definitely something wrong in the library: ptr_list::unique() leaked like crasy. the cvs is updated. -Thorsten
participants (3)
-
Caleb Epstein
-
Jonathan Wakely
-
Thorsten Ottosen