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: Jens Weller (JensWeller_at_[hidden])
Date: 2008-10-08 13:52:14

Have you tested this also on SVN Version?
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

-- 
Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger