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 14:00:18

Jens Weller wrote:
> Have you tested this also on SVN Version?

Yeah, same errors.  Though as I say it has turned out to be very hard to
isolate.

-t

> I've had the same/similar problem, and using the SVN Version helped.
> 
> regards
> 
> Jens Weller
> 
> -------- Original-Nachricht --------
>> Datum: Wed, 08 Oct 2008 13:37:17 -0400
>> Von: "troy d. straszheim" <troy_at_[hidden]>
>> An: boost-users_at_[hidden]
>> Betreff: Re: [Boost-users] serialization 1.36.0 extended_type_info	exit	issue(s)
> 
>> 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,
>> _______________________________________________
>> Boost-users mailing list
>> Boost-users_at_[hidden]
>> http://lists.boost.org/mailman/listinfo.cgi/boost-users
>