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

Hm, I had a similar error, and SVN fixed it in September. But I don't know which Plattform/Compiler you use.

-------- Original-Nachricht --------
> Datum: Wed, 08 Oct 2008 14:00:18 -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)

> 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
> > 
> 
> _______________________________________________
> Boost-users mailing list
> Boost-users_at_[hidden]
> http://lists.boost.org/mailman/listinfo.cgi/boost-users

-- 
GMX Kostenlose Spiele: Einfach online spielen und Spaß haben mit Pastry Passion!
http://games.entertainment.gmx.net/de/entertainment/games/free/puzzle/6169196