Re: [Boost-users] serialization 1.36.0 extended_type_info exit issue(s)

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" An: boost-users@lists.boost.org 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(! singletondetail::ktmap::is_destroyed()){ 89 detail::ktmap & x = singletondetail::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(! singletondetail::ktmap::is_destroyed()){ 89 detail::ktmap & x = singletondetail::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@lists.boost.org 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