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

Subject: Re: [Boost-users] serialization 1.36.0 extended_type_info exitissue(s)
From: Robert Ramey (ramey_at_[hidden])
Date: 2008-09-30 20:37:06

I'm doubting that its the complexity of the class.

More likely that its the "last" class.

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.

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.

Robert Ramey

Robert Mecklenburg wrote:
> Robert Ramey writes:
>> Its currently in the trunk - head version.  I can't test it and
>> it doesn't fail on any test platforms, so its up to you guys
>> to test it.
>
> I checked out the trunk and tested some of my code.  Of the five
> classes I tested, four unit tests now pass cleanly.  One of them still
> seg faults with the same stack trace as before.
>
>
> (gdb) where
> #0  std::_Rb_tree_rebalance_for_erase (__z=0x8072fb8,
> __header=@0xb7bfbde0) at ../../../../src/libstdc++-v3/src/tree.cc:337
> #1  0xb7bc9f93 in
>   boost::serialization::extended_type_info::key_unregister () from
> /home/mecklen/work/boost-install/lib/libboost_serialization-gcc42-mt-1_37.so.1.37.0
>   #2  0xb7bca0ef in
> boost::serialization::extended_type_info::~extended_type_info () from
> /home/mecklen/work/boost-install/lib/libboost_serialization-gcc42-mt-1_37.so.1.37.0
> #3  0xb7bcaa28 in
> boost::serialization::detail::extended_type_info_typeid_0::~extended_type_info_typeid_0
> () from
> /home/mecklen/work/boost-install/lib/libboost_serialization-gcc42-mt-1_37.so.1.37.0
> #4  0xb7690084 in exit () from /lib/tls/i686/cmov/libc.so.6 #5
> 0xb7678458 in __libc_start_main () from /lib/tls/i686/cmov/libc.so.6
> #6  0x0805c0c1 in _start ()
>
>
> I don't really see any difference between the classes that work versus
> the one that fails, except that the failure has more nested classes,
> but it isn't particularly more complex.
>
> Let me know if you want more info on the failing class.
>
> BTW,
>
>    Intel(R) Core(TM)2 CPU
>    Ubuntu Hardy Heron
>    g++ 4.2.3
>
> Thanks for all your effort,