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,