troy d. straszheim wrote:
Robert Mecklenburg, I'd be interested to see what you get from running your tests under valgrind like this:
valgrind --tool=memcheck --malloc-fill=FF --free-fill=EE ./my_failing_test Specifically
- what happens while all the global statics are being destroyed - Can you get a test that passes when run 'normally' to fail when run under valgrind as above?
I've been chasing this for a few days and it just got away from me for the third or fourth time. It looks like there are some double-deletes around and I wouldn't be surprised if it were a compiler or std library bug. I can come up with one only one (lame) question so far... why are the key_unregister methods of the extended_type_info classes written like this:
85 BOOST_SERIALIZATION_DECL(void) 86 extended_type_info::key_unregister() { 87 assert(NULL != m_key); 88 if(! singletondetail::ktmap::is_destroyed()){ 89 detail::ktmap & x = singletondetail::ktmap::get_mutable_instance(); 90 detail::ktmap::iterator start = x.lower_bound(this); 91 detail::ktmap::iterator end = x.upper_bound(this); 92 assert(start != end); 93 94 // remove entry in map which corresponds to this type 95 do{ 96 if(this == *start) 97 x.erase(start++); 98 else 99 ++start; 100 }while(start != end); 101 } 102 m_key = NULL; 103 }
instead of, say,
85 BOOST_SERIALIZATION_DECL(void) 86 extended_type_info::key_unregister() { 87 assert(NULL != m_key); 88 if(! singletondetail::ktmap::is_destroyed()){ 89 detail::ktmap & x = singletondetail::ktmap::get_mutable_instance(); 97 x.erase(this); 101 } 102 m_key = NULL; 103 }
It is possible for the same type to be in the registry more than once. This can occur when code for a serializable type is loaded in a DLL. When the DLL unloads, it takes its code with it. So vtable displatch won't work any more and will crash if used. So its important to remove the member which correponds to the exact extended_type_info record being destroyed. Erasing just one which matches the current type is not enough. Robert Ramey