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://listarchives.boost.org/mailman/listinfo.cgi/boost-users
>