Re: [Boost-users] serialization 1.36.0 extended_type_info exit issue(s)

Subject: Re: [Boost-users] serialization 1.36.0 extended_type_info exit issue(s)
From: troy d. straszheim (troy_at_[hidden])
Date: 2008-10-08 13:37:17

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(! singleton<detail::ktmap>::is_destroyed()){
89	        detail::ktmap & x = singleton<detail::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(! singleton<detail::ktmap>::is_destroyed()){
89	        detail::ktmap & x = singleton<detail::ktmap>::get_mutable_instance();
97	        x.erase(this);
101	    }
102	    m_key = NULL;
103	}

Thanks in advance,

-t

Robert Mecklenburg wrote:
> Robert Ramey writes:
>> I'm doubting that its the complexity of the class.
> 
> Sure, I agree.  I was just trying to provide more info.
> 
> 
>> More likely that its the "last" class.
> 
> In the tests I am rrunning, each boost unit test is linked with its
> own main, so no two serialization tests run together.  One of those
> tests fails.
> 
> 
>> Also it might be relevant that your using a multicore processor.
>> The library presumes that everything before entering main
>> and after leavnig main is run on a single thread.  This seems
>> like a reasonable presumption to me.  You might look into
>> this.
> 
> All of the individual tests are single threaded (although for build
> reasons they are linked with the mt libraries).  That is, no test
> creates any additional threads.
> 
> 
>> You should also run the test with break points set on
>>
>> ~singleton(){
>>     m_is_destroyed = true; // <<< break here
>> }
>>
>> To verify that this isn't getting called at an unexpected time.
> 
> I've done this and the destructor is called 15 times.  It isn't
> obvious to me if this is unexpected (since this could be the base
> class of a hierarchy of singletons).
> 
> Each time it is invoked on a different instance of this.  Breakpoints
> and stack traces are at the end of this message.  In the final call to
> ~singleton the object address is identical to the address of the
> ~extended_type_info object in the seg fault stack trace.
> 
> Note that only the primary thread is ever created.  Also, this unit
> test contains only a single top-level call to the serialization code.
> Of course, there are nested objects being serialized.
> 
> Hope this helps.  Let me know if there are more tests I can run.
> 
> Thanks,