Tim St. Clair | 18 Aug 21:48

serialization 1.36.0 extended_type_info exit issue(s)

Folks,

    I'm running some serialization unit-tests which pass with flying colors under 1.35.0 and earlier, however they seg-fault on exit when run through 1.36.0. 

    The error appears to deal with destruction of extended_type_info_typeid objects, and *only* manifests itself when I load an archive through a shared_ptr<T>.  The load will appear to function properly, then on exit of the application, <<Death>>.  This occurs even if I remove BOOST_CLASS_EXPORT && BOOST_CLASS_TYPE_INFO as the shared_ptr is to the derived element, and I'm not testing through a base.

    My lastest guess is that I may be missing some #define BOOST_SOME_MAGIC_NEW_OPTION

//////////////////////////// pseduo code: ////////////////////////////
BOOST_AUTO_TEST_CASE( MyTestClass_Serialization )
{
    boost::shared_ptr<MyTestClass> outtie ( new MyTestClass() );
    boost::shared_ptr<MyTestClass> innie;
   
    std::ofstream os( "MyTestClass_Serialization.xml", std::ios_base::out );
    my_pack< MyTestClass >( os, outtie );
    os.close();      

    std::ifstream is( "MyTestClass_Serialization.xml", std::ios_base::in );
    my_unpack< MyTestClass >( is, innie );
    is.close();
  
    BOOST_CHECK_NO_THROW();
}

//////////////////////////// ddd output: ////////////////////////////
*** No errors detected
[New Thread 0xb73e26c0 (LWP 4715)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb73e26c0 (LWP 4715)]
0xb76bb56b in std::_Rb_tree_rebalance_for_erase () from /usr/lib/libstdc++.so.6
(gdb) bt
#0  0xb76bb56b in std::_Rb_tree_rebalance_for_erase () from /usr/lib/libstdc++.so.6
#1  0xb7a38221 in std::_Rb_tree<boost::serialization::detail::extended_type_info_typeid_0 const*, boost::serialization::detail::extended_type_info_typeid_0 const*, std::_Identity<boost::serialization::detail::extended_type_info_typeid_0 const*>, boost::serialization::detail::type_compare, std::allocator<boost::serialization::detail::extended_type_info_typeid_0 const*> >::erase (this=0xb7a93c94, __position={_M_node = 0x810a3f8}) at /usr/include/c++/4.2/bits/stl_tree.h:1261
#2  0xb7a38270 in std::multiset<boost::serialization::detail::extended_type_info_typeid_0 const*, boost::serialization::detail::type_compare, std::allocator<boost::serialization::detail::extended_type_info_typeid_0 const*> >::erase (this=0xb7a93c94, __position={_M_node = 0x810a3f8}) at /usr/include/c++/4.2/bits/stl_multiset.h:346
#3  0xb7a37482 in boost::serialization::detail::extended_type_info_typeid_0::type_unregister (this=0x810749c) at /opt/tomodev/env/boost/libs/serialization/src/extended_type_info_typeid.cpp:93
#4  0x080b001a in ~extended_type_info_typeid (this=0x810749c) at /opt/tomodev/env/boost/boost/serialization/extended_type_info_typeid.hpp:80
#5  0x0809ebe2 in __tcf_49 () at /opt/tomodev/env/boost/boost/serialization/singleton.hpp:104
#6  0xb74f7084 in exit () from /lib/tls/i686/cmov/libc.so.6
#7  0xb74df458 in __libc_start_main () from /lib/tls/i686/cmov/libc.so.6
#8  0x0809e691 in _start ()
   

Cheers,
Timothy St. Clair
[timothysc <at> gmail.com]
_______________________________________________
Boost-users mailing list
Boost-users <at> lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/boost-users
Robert Ramey | 18 Aug 23:31

Re: serialization 1.36.0 extended_type_info exit issue(s)

More likely a bug introduced by recent improvements in handling automatic registering/deregistering.
 
Please make a small test case (below isn't complete) along with information about compiler, os,
etc and open up a TRAK item.
 
Robert Ramey
 
Folks,

    I'm running some serialization unit-tests which pass with flying colors under 1.35.0 and earlier, however they seg-fault on exit when run through 1.36.0. 

    The error appears to deal with destruction of extended_type_info_typeid objects, and *only* manifests itself when I load an archive through a shared_ptr<T>.  The load will appear to function properly, then on exit of the application, <<Death>>.  This occurs even if I remove BOOST_CLASS_EXPORT && BOOST_CLASS_TYPE_INFO as the shared_ptr is to the derived element, and I'm not testing through a base.

    My lastest guess is that I may be missing some #define BOOST_SOME_MAGIC_NEW_OPTION

//////////////////////////// pseduo code: ////////////////////////////
BOOST_AUTO_TEST_CASE( MyTestClass_Serialization )
{
    boost::shared_ptr<MyTestClass> outtie ( new MyTestClass() );
    boost::shared_ptr<MyTestClass> innie;
   
    std::ofstream os( "MyTestClass_Serialization.xml", std::ios_base::out );
    my_pack< MyTestClass >( os, outtie );
    os.close();      

    std::ifstream is( "MyTestClass_Serialization.xml", std::ios_base::in );
    my_unpack< MyTestClass >( is, innie );
    is.close();
  
    BOOST_CHECK_NO_THROW();
}

//////////////////////////// ddd output: ////////////////////////////
*** No errors detected
[New Thread 0xb73e26c0 (LWP 4715)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb73e26c0 (LWP 4715)]
0xb76bb56b in std::_Rb_tree_rebalance_for_erase () from /usr/lib/libstdc++.so.6
(gdb) bt
#0  0xb76bb56b in std::_Rb_tree_rebalance_for_erase () from /usr/lib/libstdc++.so.6
#1  0xb7a38221 in std::_Rb_tree<boost::serialization::detail::extended_type_info_typeid_0 const*, boost::serialization::detail::extended_type_info_typeid_0 const*, std::_Identity<boost::serialization::detail::extended_type_info_typeid_0 const*>, boost::serialization::detail::type_compare, std::allocator<boost::serialization::detail::extended_type_info_typeid_0 const*> >::erase (this=0xb7a93c94, __position={_M_node = 0x810a3f8}) at /usr/include/c++/4.2/bits/stl_tree.h:1261
#2  0xb7a38270 in std::multiset<boost::serialization::detail::extended_type_info_typeid_0 const*, boost::serialization::detail::type_compare, std::allocator<boost::serialization::detail::extended_type_info_typeid_0 const*> >::erase (this=0xb7a93c94, __position={_M_node = 0x810a3f8}) at /usr/include/c++/4.2/bits/stl_multiset.h:346
#3  0xb7a37482 in boost::serialization::detail::extended_type_info_typeid_0::type_unregister (this=0x810749c) at /opt/tomodev/env/boost/libs/serialization/src/extended_type_info_typeid.cpp:93
#4  0x080b001a in ~extended_type_info_typeid (this=0x810749c) at /opt/tomodev/env/boost/boost/serialization/extended_type_info_typeid.hpp:80
#5  0x0809ebe2 in __tcf_49 () at /opt/tomodev/env/boost/boost/serialization/singleton.hpp:104
#6  0xb74f7084 in exit () from /lib/tls/i686/cmov/libc.so.6
#7  0xb74df458 in __libc_start_main () from /lib/tls/i686/cmov/libc.so.6
#8  0x0809e691 in _start ()
   

Cheers,
Timothy St. Clair
[timothysc <at> gmail.com]

_______________________________________________
Boost-users mailing list
Boost-users <at> lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/boost-users
_______________________________________________
Boost-users mailing list
Boost-users <at> lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/boost-users
Tim St. Clair | 18 Aug 23:43

Re: serialization 1.36.0 extended_type_info exit issue(s)

I submitted a bug, let me know if you require more info, I believe it's pretty complete. 

Cheers,
Tim

On Mon, Aug 18, 2008 at 4:31 PM, Robert Ramey <ramey <at> rrsd.com> wrote:
More likely a bug introduced by recent improvements in handling automatic registering/deregistering.
 
Please make a small test case (below isn't complete) along with information about compiler, os,
etc and open up a TRAK item.
 
Robert Ramey
 
Folks,

    I'm running some serialization unit-tests which pass with flying colors under 1.35.0 and earlier, however they seg-fault on exit when run through 1.36.0. 

    The error appears to deal with destruction of extended_type_info_typeid objects, and *only* manifests itself when I load an archive through a shared_ptr<T>.  The load will appear to function properly, then on exit of the application, <<Death>>.  This occurs even if I remove BOOST_CLASS_EXPORT && BOOST_CLASS_TYPE_INFO as the shared_ptr is to the derived element, and I'm not testing through a base.

    My lastest guess is that I may be missing some #define BOOST_SOME_MAGIC_NEW_OPTION

//////////////////////////// pseduo code: ////////////////////////////
BOOST_AUTO_TEST_CASE( MyTestClass_Serialization )
{
    boost::shared_ptr<MyTestClass> outtie ( new MyTestClass() );
    boost::shared_ptr<MyTestClass> innie;
   
    std::ofstream os( "MyTestClass_Serialization.xml", std::ios_base::out );
    my_pack< MyTestClass >( os, outtie );
    os.close();      

    std::ifstream is( "MyTestClass_Serialization.xml", std::ios_base::in );
    my_unpack< MyTestClass >( is, innie );
    is.close();
  
    BOOST_CHECK_NO_THROW();
}

//////////////////////////// ddd output: ////////////////////////////
*** No errors detected
[New Thread 0xb73e26c0 (LWP 4715)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb73e26c0 (LWP 4715)]
0xb76bb56b in std::_Rb_tree_rebalance_for_erase () from /usr/lib/libstdc++.so.6
(gdb) bt
#0  0xb76bb56b in std::_Rb_tree_rebalance_for_erase () from /usr/lib/libstdc++.so.6
#1  0xb7a38221 in std::_Rb_tree<boost::serialization::detail::extended_type_info_typeid_0 const*, boost::serialization::detail::extended_type_info_typeid_0 const*, std::_Identity<boost::serialization::detail::extended_type_info_typeid_0 const*>, boost::serialization::detail::type_compare, std::allocator<boost::serialization::detail::extended_type_info_typeid_0 const*> >::erase (this=0xb7a93c94, __position={_M_node = 0x810a3f8}) at /usr/include/c++/4.2/bits/stl_tree.h:1261
#2  0xb7a38270 in std::multiset<boost::serialization::detail::extended_type_info_typeid_0 const*, boost::serialization::detail::type_compare, std::allocator<boost::serialization::detail::extended_type_info_typeid_0 const*> >::erase (this=0xb7a93c94, __position={_M_node = 0x810a3f8}) at /usr/include/c++/4.2/bits/stl_multiset.h:346
#3  0xb7a37482 in boost::serialization::detail::extended_type_info_typeid_0::type_unregister (this=0x810749c) at /opt/tomodev/env/boost/libs/serialization/src/extended_type_info_typeid.cpp:93
#4  0x080b001a in ~extended_type_info_typeid (this=0x810749c) at /opt/tomodev/env/boost/boost/serialization/extended_type_info_typeid.hpp:80
#5  0x0809ebe2 in __tcf_49 () at /opt/tomodev/env/boost/boost/serialization/singleton.hpp:104
#6  0xb74f7084 in exit () from /lib/tls/i686/cmov/libc.so.6
#7  0xb74df458 in __libc_start_main () from /lib/tls/i686/cmov/libc.so.6
#8  0x0809e691 in _start ()
   

Cheers,
Timothy St. Clair
[timothysc <at> gmail.com]

_______________________________________________
Boost-users mailing list
Boost-users <at> lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/boost-users

_______________________________________________
Boost-users mailing list
Boost-users <at> lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/boost-users



--
Regards,
Timothy St. Clair
[timothysc <at> gmail.com]
_______________________________________________
Boost-users mailing list
Boost-users <at> lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/boost-users
Robert Mecklenburg | 20 Aug 21:43

Re: serialization 1.36.0 extended_type_info exit issue(s)

Tim St. Clair writes:
 >     I'm running some serialization unit-tests which pass with flying colors
 > under 1.35.0 and earlier, however they seg-fault on exit when run through
 > 1.36.0.
 > ...
 > Program received signal SIGSEGV, Segmentation fault.
 > [Switching to Thread 0xb73e26c0 (LWP 4715)]
 > 0xb76bb56b in std::_Rb_tree_rebalance_for_erase () from
 > /usr/lib/libstdc++.so.6

I am having similar problems, only there are no shared pointers
involved.  I was getting this segv also, but as I pared the example
down and it mutated into a memory corruption problem:

    *** glibc detected *** ./serio: double free or corruption (fasttop): 0x0805c5c8 ***
    ======= Backtrace: =========
    /lib/tls/i686/cmov/libc.so.6[0xb7cd5a85]
    /lib/tls/i686/cmov/libc.so.6(cfree+0x90)[0xb7cd94f0]
    /usr/lib/libstdc++.so.6(_ZdlPv+0x21)[0xb7ea1b11]
    /home/mecklen/work/boost-install/lib/libboost_serialization-gcc42-mt-1_36.so.1.36.0(_ZN5boost13serialization6detail27extended_type_info_typeid_015type_unregisterEv+0xf6)[0xb7f3c8d6]
    ./serio(_ZN5boost13serialization25extended_type_info_typeidI4DataED1Ev+0x1c)[0x805576a]
    ./serio(__gxx_personality_v0+0x35e)[0x8053f36]
    /lib/tls/i686/cmov/libc.so.6(exit+0xd4)[0xb7c98084]
    /lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe8)[0xb7c80458]
    ./serio(__gxx_personality_v0+0x69)[0x8053c41]

The problem I'm experiencing only seems to occur when the class
implementation is in a shared library.  I have attached a simple
example that reproduces the bug.

My system details are:

    Intel i686 cpu
    Ubuntu Hardy Heron
    g++ (GCC) 4.2.3 (Ubuntu 4.2.3-2ubuntu7)
    libstdc++6-4.2-dev  4.2.3-2ubuntu7 
    Boost 1.36.0
    ./configure --prefix=/home/mecklen/work/boost-install \
	--without-libraries=python \
	--without-icu --without-mpi

This is a real show-stopper for us.  Any help would be greatly
appreciated.

Thanks,
-- 
Robert
// g++ -I/home/mecklen/work/boost-install/include/boost-1_36 serio.cpp -o serio
-L/home/mecklen/work/boost-install/lib/ -lboost_serialization-gcc42-mt -lboost_unit_test_framework-gcc42-mt

#define BOOST_TEST_DYN_LINK
#define BOOST_TEST_MAIN

#include <boost/test/auto_unit_test.hpp>
#include <boost/archive/text_oarchive.hpp>
#include <sstream>

struct Data
{
    Data() : n_(10) {}
    template <class Archive> void serialize(Archive & ar, const unsigned version);
    int n_;
};

BOOST_AUTO_TEST_CASE(serioTest)
{
    Data d;
    std::ostringstream os;
    boost::archive::text_oarchive oa(os);

    oa & d;                     // <<<<< Remove this and no crash.
}
#include <boost/archive/text_oarchive.hpp>         // serialization::text_oarchive
#include <boost/serialization/export.hpp>

struct Data
{
    Data() : n_(10) {}
    template <class Archive> void serialize(Archive & ar, const unsigned version);
    int n_;
};

BOOST_CLASS_EXPORT(Data);

template <class Archive>
void
Data::serialize(Archive & ar, const unsigned /* version */)
{
    ar & n_;
}
#! /bin/bash -x
rm -f serioblob.o libserioblob.so serio.o serio

g++ -I/home/mecklen/work/boost-install/include/boost-1_36 serioblob.cpp -c -o serioblob.o

g++ -g  -ftrapv  -DBOOST_1_36_0 -I/home/mecklen/work/boost-install/include/boost-1_36 -DUSE_TRAPV
-rdynamic  -shared serioblob.o -L/home/mecklen/work/boost-install/lib/
-lboost_serialization-gcc42-mt -o libserioblob.so

g++ -I/home/mecklen/work/boost-install/include/boost-1_36 serio.cpp -c -o serio.o

g++ -g  -ftrapv  -DBOOST_1_36_0 -I/home/mecklen/work/boost-install/include/boost-1_36 -DUSE_TRAPV
-rdynamic  serio.o libserioblob.so
/home/mecklen/work/boost-install/lib/libboost_unit_test_framework-gcc42-mt.so
-L/home/mecklen/work/boost-install/lib/ -lboost_serialization-gcc42-mt -o serio

export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/home/mecklen/work/boost-install/lib:.
./serio --catch_system_errors=no
_______________________________________________
Boost-users mailing list
Boost-users <at> lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/boost-users
Robert Ramey | 20 Aug 23:02

Re: serialization 1.36.0 extended_type_info exitissue(s)

This has been reported in two trak items.

I've looked at it and made changes which I believe will
address the problem.  But I haven't been able to test it
yet.

Robert.

Robert Mecklenburg wrote:
>> Tim St. Clair writes:
>>>     I'm running some serialization unit-tests which pass with
>>> flying colors under 1.35.0 and earlier, however they seg-fault on
>>> exit when run through
>>> 1.36.0.
>>> ...
>>> Program received signal SIGSEGV, Segmentation fault.
>>> [Switching to Thread 0xb73e26c0 (LWP 4715)]
>>> 0xb76bb56b in std::_Rb_tree_rebalance_for_erase () from
>>> /usr/lib/libstdc++.so.6
>>
>> I am having similar problems, only there are no shared pointers
>> involved.  I was getting this segv also, but as I pared the example
>> down and it mutated into a memory corruption problem:
>>
>>    *** glibc detected *** ./serio: double free or corruption
>>    (fasttop): 0x0805c5c8 *** ======= Backtrace: =========
>>    /lib/tls/i686/cmov/libc.so.6[0xb7cd5a85]
>>    /lib/tls/i686/cmov/libc.so.6(cfree+0x90)[0xb7cd94f0]
>>    /usr/lib/libstdc++.so.6(_ZdlPv+0x21)[0xb7ea1b11]
>>
>>
>>
>>
>>
>>
>> /home/mecklen/work/boost-install/lib/libboost_serialization-gcc42-mt-1_36.so.1.36.0(_ZN5boost13serialization6detail27extended_type_info_typeid_015type_unregisterEv+0xf6)[0xb7f3c8d6]
>> ./serio(_ZN5boost13serialization25extended_type_info_typeidI4DataED1Ev+0x1c)[0x805576a]
>> ./serio(__gxx_personality_v0+0x35e)[0x8053f36]
>> /lib/tls/i686/cmov/libc.so.6(exit+0xd4)[0xb7c98084]
>> /lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe8)[0xb7c80458]
>> ./serio(__gxx_personality_v0+0x69)[0x8053c41]
>>
>> The problem I'm experiencing only seems to occur when the class
>> implementation is in a shared library.  I have attached a simple
>> example that reproduces the bug.
>>
>> My system details are:
>>
>>    Intel i686 cpu
>>    Ubuntu Hardy Heron
>>    g++ (GCC) 4.2.3 (Ubuntu 4.2.3-2ubuntu7)
>>    libstdc++6-4.2-dev  4.2.3-2ubuntu7
>>    Boost 1.36.0
>>    ./configure --prefix=/home/mecklen/work/boost-install \
>> --without-libraries=python \
>> --without-icu --without-mpi
>>
>> This is a real show-stopper for us.  Any help would be greatly
>> appreciated.
>>
>> Thanks,
>> --
>> Robert
>>
>
>
>
>> // g++ -I/home/mecklen/work/boost-install/include/boost-1_36
>> serio.cpp -o serio -L/home/mecklen/work/boost-install/lib/
>> -lboost_serialization-gcc42-mt -lboost_unit_test_framework-gcc42-mt
>>
>> #define BOOST_TEST_DYN_LINK
>> #define BOOST_TEST_MAIN
>>
>> #include <boost/test/auto_unit_test.hpp>
>> #include <boost/archive/text_oarchive.hpp>
>> #include <sstream>
>>
>> struct Data
>> {
>>    Data() : n_(10) {}
>>    template <class Archive> void serialize(Archive & ar, const
>>    unsigned version); int n_;
>> };
>>
>> BOOST_AUTO_TEST_CASE(serioTest)
>> {
>>    Data d;
>>    std::ostringstream os;
>>    boost::archive::text_oarchive oa(os);
>>
>>    oa & d;                     // <<<<< Remove this and no crash.
>> }
>>
>
>
>
>> #include <boost/archive/text_oarchive.hpp>         //
>> serialization::text_oarchive #include
>> <boost/serialization/export.hpp>
>>
>> struct Data
>> {
>>    Data() : n_(10) {}
>>    template <class Archive> void serialize(Archive & ar, const
>>    unsigned version); int n_;
>> };
>>
>> BOOST_CLASS_EXPORT(Data);
>>
>> template <class Archive>
>> void
>> Data::serialize(Archive & ar, const unsigned /* version */)
>> {
>>    ar & n_;
>> }
>>
>
>
>
>> #! /bin/bash -x
>> rm -f serioblob.o libserioblob.so serio.o serio
>>
>> g++ -I/home/mecklen/work/boost-install/include/boost-1_36
>> serioblob.cpp -c -o serioblob.o
>>
>> g++ -g  -ftrapv  -DBOOST_1_36_0
>> -I/home/mecklen/work/boost-install/include/boost-1_36 -DUSE_TRAPV
>> -rdynamic  -shared serioblob.o
>> -L/home/mecklen/work/boost-install/lib/
>> -lboost_serialization-gcc42-mt -o libserioblob.so
>>
>> g++ -I/home/mecklen/work/boost-install/include/boost-1_36 serio.cpp
>> -c -o serio.o
>>
>> g++ -g  -ftrapv  -DBOOST_1_36_0
>> -I/home/mecklen/work/boost-install/include/boost-1_36 -DUSE_TRAPV
>> -rdynamic  serio.o libserioblob.so
>> /home/mecklen/work/boost-install/lib/libboost_unit_test_framework-gcc42-mt.so
>> -L/home/mecklen/work/boost-install/lib/
>> -lboost_serialization-gcc42-mt -o serio
>>
>> export
>> LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/home/mecklen/work/boost-install/lib:.
>> ./serio --catch_system_errors=no
>>
>
>
>
>> _______________________________________________
>> Boost-users mailing list
>> Boost-users <at> lists.boost.org
>> http://lists.boost.org/mailman/listinfo.cgi/boost-users 
Robert Mecklenburg | 20 Aug 22:19

Re: serialization 1.36.0 extended_type_info exitissue(s)

Robert Ramey writes:
> This has been reported in two trak items.

Sorry to waste bandwidth.

> I've looked at it and made changes which I believe will address the
> problem.  But I haven't been able to test it yet.

Is there any way I can help test your patch?

Thanks,
--

-- 
Robert
troy d. straszheim | 1 Sep 06:44

Re: serialization 1.36.0 extended_type_info exitissue(s)

Robert Ramey wrote:
> This has been reported in two trak items.
> 
> I've looked at it and made changes which I believe will
> address the problem.  But I haven't been able to test it
> yet.
> 
> Robert.
> 

Hey Robert,

Got any hints on what is going on here?  svn revision#
of the relevant changes?   We've hit this one as well, looking
for a workaround, not making much progress.

-t
Robert Ramey | 1 Sep 07:47

Re: serialization 1.36.0extended_type_info exitissue(s)

I've addressed it on my personal copy. Just now passed tests on my
local machine.  I will be uploading to the trunk soon.  Unfortunately
I can't be sure my changes fix the problem as it doesn't manifest
itself on my machine.

Robert Ramey

troy d. straszheim wrote:
> Robert Ramey wrote:
>> This has been reported in two trak items.
>>
>> I've looked at it and made changes which I believe will
>> address the problem.  But I haven't been able to test it
>> yet.
>>
>> Robert.
>>
>
> Hey Robert,
>
> Got any hints on what is going on here?  svn revision#
> of the relevant changes?   We've hit this one as well, looking
> for a workaround, not making much progress.
>
> -t 
troy d. straszheim | 1 Sep 18:07

Re: serialization 1.36.0extended_type_info exitissue(s)

Robert Ramey wrote:
> I've addressed it on my personal copy. Just now passed tests on my
> local machine.  I will be uploading to the trunk soon.  Unfortunately
> I can't be sure my changes fix the problem as it doesn't manifest
> itself on my machine.

OK, just ping this thread, I'll give it some exercise.

Thanks,

-t
Ken Roser | 30 Sep 03:30
Favicon

Re: serialization 1.36.0extended_type_info exitissue(s)

Will this fix show up in a 1.36.1 release or not until 1.37.0.

Can you provide me the svn version number that has the fix?

Robert Ramey wrote:
> I've addressed it on my personal copy. Just now passed tests on my
> local machine.  I will be uploading to the trunk soon.  Unfortunately
> I can't be sure my changes fix the problem as it doesn't manifest
> itself on my machine.
>
> Robert Ramey
>
> troy d. straszheim wrote:
>   
>> Robert Ramey wrote:
>>     
>>> This has been reported in two trak items.
>>>
>>> I've looked at it and made changes which I believe will
>>> address the problem.  But I haven't been able to test it
>>> yet.
>>>
>>> Robert.
>>>
>>>       
>> Hey Robert,
>>
>> Got any hints on what is going on here?  svn revision#
>> of the relevant changes?   We've hit this one as well, looking
>> for a workaround, not making much progress.
>>
>> -t 
>>     
>
>
>
> _______________________________________________
> Boost-users mailing list
> Boost-users <at> lists.boost.org
> http://lists.boost.org/mailman/listinfo.cgi/boost-users
>   
Robert Ramey | 30 Sep 08:05

Re: serialization 1.36.0extended_type_info exitissue(s)

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.

Robert Ramey

Ken Roser wrote:
> Will this fix show up in a 1.36.1 release or not until 1.37.0.
>
> Can you provide me the svn version number that has the fix?
>
> Robert Ramey wrote:
>> I've addressed it on my personal copy. Just now passed tests on my
>> local machine.  I will be uploading to the trunk soon.  Unfortunately
>> I can't be sure my changes fix the problem as it doesn't manifest
>> itself on my machine.
>>
>> Robert Ramey
>>
>> troy d. straszheim wrote:
>>
>>> Robert Ramey wrote:
>>>
>>>> This has been reported in two trak items.
>>>>
>>>> I've looked at it and made changes which I believe will
>>>> address the problem.  But I haven't been able to test it
>>>> yet.
>>>>
>>>> Robert.
>>>>
>>>>
>>> Hey Robert,
>>>
>>> Got any hints on what is going on here?  svn revision#
>>> of the relevant changes?   We've hit this one as well, looking
>>> for a workaround, not making much progress.
>>>
>>> -t
>>>
>>
>>
>>
>> _______________________________________________
>> Boost-users mailing list
>> Boost-users <at> lists.boost.org
>> http://lists.boost.org/mailman/listinfo.cgi/boost-users 
Robert Mecklenburg | 30 Sep 23:57

Re: serialization 1.36.0 extended_type_info exit issue(s)

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,
--

-- 
Robert
Robert Ramey | 1 Oct 02:37

Re: serialization 1.36.0 extended_type_info exitissue(s)

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, 
Robert Mecklenburg | 1 Oct 18:22

Re: serialization 1.36.0 extended_type_info exit issue(s)

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,
-- 
Robert

(gdb) list singleton.hpp:120
115	        return get_instance();
116	    }
117	    BOOST_DLLEXPORT static const T & get_const_instance(){
118	        return get_instance();
119	    }
120	    BOOST_DLLEXPORT static bool is_destroyed(){
121	        return m_is_destroyed;
122	    }
123	    ~singleton(){
124	        m_is_destroyed = true;
(gdb) b 124
Breakpoint 1 at 0x807ba0e: file
/home/mecklen/work/boost-install/include/boost-1_37/boost/serialization/singleton.hpp,
line 124. (18 locations)
(gdb) run
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /home/mecklen/s5w/trunk/core/common/src/test/SampleBinTest --catch_system_errors=no
[Thread debugging using libthread_db enabled]
Running 5 test cases...
[New Thread 0xb73e16c0 (LWP 861)]

*** No errors detected
[Switching to Thread 0xb73e16c0 (LWP 861)]

Breakpoint 1, ~singleton (this=0xb7f12294) at /home/mecklen/work/boost-install/include/boost-1_37/boost/serialization/singleton.hpp:124
124	        m_is_destroyed = true;
(gdb) where
#0  ~singleton (this=0xb7f12294) at /home/mecklen/work/boost-install/include/boost-1_37/boost/serialization/singleton.hpp:124
#1  0xb7dc4c65 in ~extended_type_info_typeid (this=0xb7f12294) at /home/mecklen/work/boost-install/include/boost-1_37/boost/serialization/extended_type_info_typeid.hpp:80
#2  0xb7dc42c4 in __tcf_0 () at /home/mecklen/work/boost-install/include/boost-1_37/boost/serialization/singleton.hpp:105
#3  0xb75933b1 in __cxa_finalize () from /lib/tls/i686/cmov/libc.so.6
#4  0xb7dc4023 in __do_global_dtors_aux () from /home/mecklen/s5w/trunk/core/common/src/libcommon.so
#5  0xb7e93a4c in _fini () from /home/mecklen/s5w/trunk/core/common/src/libcommon.so
#6  0xb7f7afcf in _dl_fini () from /lib/ld-linux.so.2
#7  0xb7593084 in exit () from /lib/tls/i686/cmov/libc.so.6
#8  0xb757b458 in __libc_start_main () from /lib/tls/i686/cmov/libc.so.6
#9  0x08077ce1 in _start ()
(gdb) cont
Continuing.

Breakpoint 1, ~singleton (this=0xb7f126cc) at /home/mecklen/work/boost-install/include/boost-1_37/boost/serialization/singleton.hpp:124
124	        m_is_destroyed = true;
(gdb) where
#0  ~singleton (this=0xb7f126cc) at /home/mecklen/work/boost-install/include/boost-1_37/boost/serialization/singleton.hpp:124
#1  0xb7dd7a5b in ~extended_type_info_typeid (this=0xb7f126cc) at /home/mecklen/work/boost-install/include/boost-1_37/boost/serialization/extended_type_info_typeid.hpp:80
#2  0xb7dd64d8 in __tcf_0 () at /home/mecklen/work/boost-install/include/boost-1_37/boost/serialization/singleton.hpp:105
#3  0xb75933b1 in __cxa_finalize () from /lib/tls/i686/cmov/libc.so.6
#4  0xb7dc4023 in __do_global_dtors_aux () from /home/mecklen/s5w/trunk/core/common/src/libcommon.so
#5  0xb7e93a4c in _fini () from /home/mecklen/s5w/trunk/core/common/src/libcommon.so
#6  0xb7f7afcf in _dl_fini () from /lib/ld-linux.so.2
#7  0xb7593084 in exit () from /lib/tls/i686/cmov/libc.so.6
#8  0xb757b458 in __libc_start_main () from /lib/tls/i686/cmov/libc.so.6
#9  0x08077ce1 in _start ()
(gdb) cont
Continuing.

Breakpoint 1, ~singleton (this=0xb7f15384) at /home/mecklen/work/boost-install/include/boost-1_37/boost/serialization/singleton.hpp:124
124	        m_is_destroyed = true;
(gdb) where
#0  ~singleton (this=0xb7f15384) at /home/mecklen/work/boost-install/include/boost-1_37/boost/serialization/singleton.hpp:124
#1  0xb7e4c67b in ~extended_type_info_typeid (this=0xb7f15384) at /home/mecklen/work/boost-install/include/boost-1_37/boost/serialization/extended_type_info_typeid.hpp:80
#2  0xb7e4a3f0 in __tcf_0 () at /home/mecklen/work/boost-install/include/boost-1_37/boost/serialization/singleton.hpp:105
#3  0xb75933b1 in __cxa_finalize () from /lib/tls/i686/cmov/libc.so.6
#4  0xb7dc4023 in __do_global_dtors_aux () from /home/mecklen/s5w/trunk/core/common/src/libcommon.so
#5  0xb7e93a4c in _fini () from /home/mecklen/s5w/trunk/core/common/src/libcommon.so
#6  0xb7f7afcf in _dl_fini () from /lib/ld-linux.so.2
#7  0xb7593084 in exit () from /lib/tls/i686/cmov/libc.so.6
#8  0xb757b458 in __libc_start_main () from /lib/tls/i686/cmov/libc.so.6
#9  0x08077ce1 in _start ()
(gdb) cont
Continuing.

Breakpoint 1, ~singleton (this=0xb7f15544) at /home/mecklen/work/boost-install/include/boost-1_37/boost/serialization/singleton.hpp:124
124	        m_is_destroyed = true;
(gdb) where
#0  ~singleton (this=0xb7f15544) at /home/mecklen/work/boost-install/include/boost-1_37/boost/serialization/singleton.hpp:124
#1  0xb7e546cd in ~extended_type_info_typeid (this=0xb7f15544) at /home/mecklen/work/boost-install/include/boost-1_37/boost/serialization/extended_type_info_typeid.hpp:80
#2  0xb7e50986 in __tcf_0 () at /home/mecklen/work/boost-install/include/boost-1_37/boost/serialization/singleton.hpp:105
#3  0xb75933b1 in __cxa_finalize () from /lib/tls/i686/cmov/libc.so.6
#4  0xb7dc4023 in __do_global_dtors_aux () from /home/mecklen/s5w/trunk/core/common/src/libcommon.so
#5  0xb7e93a4c in _fini () from /home/mecklen/s5w/trunk/core/common/src/libcommon.so
#6  0xb7f7afcf in _dl_fini () from /lib/ld-linux.so.2
#7  0xb7593084 in exit () from /lib/tls/i686/cmov/libc.so.6
#8  0xb757b458 in __libc_start_main () from /lib/tls/i686/cmov/libc.so.6
#9  0x08077ce1 in _start ()
(gdb) cont
Continuing.

Breakpoint 1, ~singleton (this=0xb7f12db0) at /home/mecklen/work/boost-install/include/boost-1_37/boost/serialization/singleton.hpp:124
124	        m_is_destroyed = true;
(gdb) where
#0  ~singleton (this=0xb7f12db0) at /home/mecklen/work/boost-install/include/boost-1_37/boost/serialization/singleton.hpp:124
#1  0xb7e26d55 in ~extended_type_info_typeid (this=0xb7f12db0) at /home/mecklen/work/boost-install/include/boost-1_37/boost/serialization/extended_type_info_typeid.hpp:80
#2  0xb7e239e2 in __tcf_19 () at /home/mecklen/work/boost-install/include/boost-1_37/boost/serialization/singleton.hpp:105
#3  0xb75933b1 in __cxa_finalize () from /lib/tls/i686/cmov/libc.so.6
#4  0xb7dc4023 in __do_global_dtors_aux () from /home/mecklen/s5w/trunk/core/common/src/libcommon.so
#5  0xb7e93a4c in _fini () from /home/mecklen/s5w/trunk/core/common/src/libcommon.so
#6  0xb7f7afcf in _dl_fini () from /lib/ld-linux.so.2
#7  0xb7593084 in exit () from /lib/tls/i686/cmov/libc.so.6
#8  0xb757b458 in __libc_start_main () from /lib/tls/i686/cmov/libc.so.6
#9  0x08077ce1 in _start ()
(gdb) cont
Continuing.

Breakpoint 1, ~singleton (this=0xb7f1245c) at /home/mecklen/work/boost-install/include/boost-1_37/boost/serialization/singleton.hpp:124
124	        m_is_destroyed = true;
(gdb) where
#0  ~singleton (this=0xb7f1245c) at /home/mecklen/work/boost-install/include/boost-1_37/boost/serialization/singleton.hpp:124
#1  0xb7dc86d9 in ~extended_type_info_typeid (this=0xb7f1245c) at /home/mecklen/work/boost-install/include/boost-1_37/boost/serialization/extended_type_info_typeid.hpp:80
#2  0xb7dc4fec in __tcf_14 () at /home/mecklen/work/boost-install/include/boost-1_37/boost/serialization/singleton.hpp:105
#3  0xb75933b1 in __cxa_finalize () from /lib/tls/i686/cmov/libc.so.6
#4  0xb7dc4023 in __do_global_dtors_aux () from /home/mecklen/s5w/trunk/core/common/src/libcommon.so
#5  0xb7e93a4c in _fini () from /home/mecklen/s5w/trunk/core/common/src/libcommon.so
#6  0xb7f7afcf in _dl_fini () from /lib/ld-linux.so.2
#7  0xb7593084 in exit () from /lib/tls/i686/cmov/libc.so.6
#8  0xb757b458 in __libc_start_main () from /lib/tls/i686/cmov/libc.so.6
#9  0x08077ce1 in _start ()
(gdb) cont
Continuing.

Breakpoint 1, ~singleton (this=0xb7f123c4) at /home/mecklen/work/boost-install/include/boost-1_37/boost/serialization/singleton.hpp:124
124	        m_is_destroyed = true;
(gdb) where
#0  ~singleton (this=0xb7f123c4) at /home/mecklen/work/boost-install/include/boost-1_37/boost/serialization/singleton.hpp:124
#1  0xb7dc85ad in ~extended_type_info_typeid (this=0xb7f123c4) at /home/mecklen/work/boost-install/include/boost-1_37/boost/serialization/extended_type_info_typeid.hpp:80
#2  0xb7dc4fd8 in __tcf_0 () at /home/mecklen/work/boost-install/include/boost-1_37/boost/serialization/singleton.hpp:105
#3  0xb75933b1 in __cxa_finalize () from /lib/tls/i686/cmov/libc.so.6
#4  0xb7dc4023 in __do_global_dtors_aux () from /home/mecklen/s5w/trunk/core/common/src/libcommon.so
#5  0xb7e93a4c in _fini () from /home/mecklen/s5w/trunk/core/common/src/libcommon.so
#6  0xb7f7afcf in _dl_fini () from /lib/ld-linux.so.2
#7  0xb7593084 in exit () from /lib/tls/i686/cmov/libc.so.6
#8  0xb757b458 in __libc_start_main () from /lib/tls/i686/cmov/libc.so.6
#9  0x08077ce1 in _start ()
(gdb) cont
Continuing.

Breakpoint 1, ~singleton (this=0xb7f1257c) at /home/mecklen/work/boost-install/include/boost-1_37/boost/serialization/singleton.hpp:124
124	        m_is_destroyed = true;
(gdb) where
#0  ~singleton (this=0xb7f1257c) at /home/mecklen/work/boost-install/include/boost-1_37/boost/serialization/singleton.hpp:124
#1  0xb7dd3611 in ~extended_type_info_typeid (this=0xb7f1257c) at /home/mecklen/work/boost-install/include/boost-1_37/boost/serialization/extended_type_info_typeid.hpp:80
#2  0xb7dd265c in __tcf_0 () at /home/mecklen/work/boost-install/include/boost-1_37/boost/serialization/singleton.hpp:105
#3  0xb75933b1 in __cxa_finalize () from /lib/tls/i686/cmov/libc.so.6
#4  0xb7dc4023 in __do_global_dtors_aux () from /home/mecklen/s5w/trunk/core/common/src/libcommon.so
#5  0xb7e93a4c in _fini () from /home/mecklen/s5w/trunk/core/common/src/libcommon.so
#6  0xb7f7afcf in _dl_fini () from /lib/ld-linux.so.2
#7  0xb7593084 in exit () from /lib/tls/i686/cmov/libc.so.6
#8  0xb757b458 in __libc_start_main () from /lib/tls/i686/cmov/libc.so.6
#9  0x08077ce1 in _start ()
(gdb) cont
Continuing.

Breakpoint 1, ~singleton (this=0xb7f12844) at /home/mecklen/work/boost-install/include/boost-1_37/boost/serialization/singleton.hpp:124
124	        m_is_destroyed = true;
(gdb) where
#0  ~singleton (this=0xb7f12844) at /home/mecklen/work/boost-install/include/boost-1_37/boost/serialization/singleton.hpp:124
#1  0xb7de138d in ~extended_type_info_typeid (this=0xb7f12844) at /home/mecklen/work/boost-install/include/boost-1_37/boost/serialization/extended_type_info_typeid.hpp:80
#2  0xb7ddffde in __tcf_0 () at /home/mecklen/work/boost-install/include/boost-1_37/boost/serialization/singleton.hpp:105
#3  0xb75933b1 in __cxa_finalize () from /lib/tls/i686/cmov/libc.so.6
#4  0xb7dc4023 in __do_global_dtors_aux () from /home/mecklen/s5w/trunk/core/common/src/libcommon.so
#5  0xb7e93a4c in _fini () from /home/mecklen/s5w/trunk/core/common/src/libcommon.so
#6  0xb7f7afcf in _dl_fini () from /lib/ld-linux.so.2
#7  0xb7593084 in exit () from /lib/tls/i686/cmov/libc.so.6
#8  0xb757b458 in __libc_start_main () from /lib/tls/i686/cmov/libc.so.6
#9  0x08077ce1 in _start ()
(gdb) cont
Continuing.

Breakpoint 1, ~singleton (this=0xb7f12cec) at /home/mecklen/work/boost-install/include/boost-1_37/boost/serialization/singleton.hpp:124
124	        m_is_destroyed = true;
(gdb) where
#0  ~singleton (this=0xb7f12cec) at /home/mecklen/work/boost-install/include/boost-1_37/boost/serialization/singleton.hpp:124
#1  0xb7e26afd in ~extended_type_info_typeid (this=0xb7f12cec) at /home/mecklen/work/boost-install/include/boost-1_37/boost/serialization/extended_type_info_typeid.hpp:80
#2  0xb7e239ba in __tcf_0 () at /home/mecklen/work/boost-install/include/boost-1_37/boost/serialization/singleton.hpp:105
#3  0xb75933b1 in __cxa_finalize () from /lib/tls/i686/cmov/libc.so.6
#4  0xb7dc4023 in __do_global_dtors_aux () from /home/mecklen/s5w/trunk/core/common/src/libcommon.so
#5  0xb7e93a4c in _fini () from /home/mecklen/s5w/trunk/core/common/src/libcommon.so
#6  0xb7f7afcf in _dl_fini () from /lib/ld-linux.so.2
#7  0xb7593084 in exit () from /lib/tls/i686/cmov/libc.so.6
#8  0xb757b458 in __libc_start_main () from /lib/tls/i686/cmov/libc.so.6
#9  0x08077ce1 in _start ()
(gdb) cont
Continuing.

Breakpoint 1, ~singleton (this=0xb7f157a4) at /home/mecklen/work/boost-install/include/boost-1_37/boost/serialization/singleton.hpp:124
124	        m_is_destroyed = true;
(gdb) where
#0  ~singleton (this=0xb7f157a4) at /home/mecklen/work/boost-install/include/boost-1_37/boost/serialization/singleton.hpp:124
#1  0xb7e6daaf in ~extended_type_info_typeid (this=0xb7f157a4) at /home/mecklen/work/boost-install/include/boost-1_37/boost/serialization/extended_type_info_typeid.hpp:80
#2  0xb7e6c142 in __tcf_0 () at /home/mecklen/work/boost-install/include/boost-1_37/boost/serialization/singleton.hpp:105
#3  0xb75933b1 in __cxa_finalize () from /lib/tls/i686/cmov/libc.so.6
#4  0xb7dc4023 in __do_global_dtors_aux () from /home/mecklen/s5w/trunk/core/common/src/libcommon.so
#5  0xb7e93a4c in _fini () from /home/mecklen/s5w/trunk/core/common/src/libcommon.so
#6  0xb7f7afcf in _dl_fini () from /lib/ld-linux.so.2
#7  0xb7593084 in exit () from /lib/tls/i686/cmov/libc.so.6
#8  0xb757b458 in __libc_start_main () from /lib/tls/i686/cmov/libc.so.6
#9  0x08077ce1 in _start ()
(gdb) cont
Continuing.

Breakpoint 1, ~singleton (this=0xb7f1541c) at /home/mecklen/work/boost-install/include/boost-1_37/boost/serialization/singleton.hpp:124
124	        m_is_destroyed = true;
(gdb) where
#0  ~singleton (this=0xb7f1541c) at /home/mecklen/work/boost-install/include/boost-1_37/boost/serialization/singleton.hpp:124
#1  0xb7e4c7a7 in ~extended_type_info_typeid (this=0xb7f1541c) at /home/mecklen/work/boost-install/include/boost-1_37/boost/serialization/extended_type_info_typeid.hpp:80
#2  0xb7e4a404 in __tcf_14 () at /home/mecklen/work/boost-install/include/boost-1_37/boost/serialization/singleton.hpp:105
#3  0xb75933b1 in __cxa_finalize () from /lib/tls/i686/cmov/libc.so.6
#4  0xb7dc4023 in __do_global_dtors_aux () from /home/mecklen/s5w/trunk/core/common/src/libcommon.so
#5  0xb7e93a4c in _fini () from /home/mecklen/s5w/trunk/core/common/src/libcommon.so
#6  0xb7f7afcf in _dl_fini () from /lib/ld-linux.so.2
#7  0xb7593084 in exit () from /lib/tls/i686/cmov/libc.so.6
#8  0xb757b458 in __libc_start_main () from /lib/tls/i686/cmov/libc.so.6
#9  0x08077ce1 in _start ()
(gdb) cont
Continuing.

Breakpoint 1, ~singleton (this=0xb7f12e54) at /home/mecklen/work/boost-install/include/boost-1_37/boost/serialization/singleton.hpp:124
124	        m_is_destroyed = true;
(gdb) where
#0  ~singleton (this=0xb7f12e54) at /home/mecklen/work/boost-install/include/boost-1_37/boost/serialization/singleton.hpp:124
#1  0xb7e26e81 in ~extended_type_info_typeid (this=0xb7f12e54) at /home/mecklen/work/boost-install/include/boost-1_37/boost/serialization/extended_type_info_typeid.hpp:80
#2  0xb7e239f6 in __tcf_24 () at /home/mecklen/work/boost-install/include/boost-1_37/boost/serialization/singleton.hpp:105
#3  0xb75933b1 in __cxa_finalize () from /lib/tls/i686/cmov/libc.so.6
#4  0xb7dc4023 in __do_global_dtors_aux () from /home/mecklen/s5w/trunk/core/common/src/libcommon.so
#5  0xb7e93a4c in _fini () from /home/mecklen/s5w/trunk/core/common/src/libcommon.so
#6  0xb7f7afcf in _dl_fini () from /lib/ld-linux.so.2
#7  0xb7593084 in exit () from /lib/tls/i686/cmov/libc.so.6
#8  0xb757b458 in __libc_start_main () from /lib/tls/i686/cmov/libc.so.6
#9  0x08077ce1 in _start ()
(gdb) cont
Continuing.

Breakpoint 1, ~singleton (this=0xb7f12d84) at /home/mecklen/work/boost-install/include/boost-1_37/boost/serialization/singleton.hpp:124
124	        m_is_destroyed = true;
(gdb) where
#0  ~singleton (this=0xb7f12d84) at /home/mecklen/work/boost-install/include/boost-1_37/boost/serialization/singleton.hpp:124
#1  0xb7e26c29 in ~extended_type_info_typeid (this=0xb7f12d84) at /home/mecklen/work/boost-install/include/boost-1_37/boost/serialization/extended_type_info_typeid.hpp:80
#2  0xb7e239ce in __tcf_18 () at /home/mecklen/work/boost-install/include/boost-1_37/boost/serialization/singleton.hpp:105
#3  0xb75933b1 in __cxa_finalize () from /lib/tls/i686/cmov/libc.so.6
#4  0xb7dc4023 in __do_global_dtors_aux () from /home/mecklen/s5w/trunk/core/common/src/libcommon.so
#5  0xb7e93a4c in _fini () from /home/mecklen/s5w/trunk/core/common/src/libcommon.so
#6  0xb7f7afcf in _dl_fini () from /lib/ld-linux.so.2
#7  0xb7593084 in exit () from /lib/tls/i686/cmov/libc.so.6
#8  0xb757b458 in __libc_start_main () from /lib/tls/i686/cmov/libc.so.6
#9  0x08077ce1 in _start ()
(gdb) cont
Continuing.

Breakpoint 1, ~singleton (this=0x8097d90) at /home/mecklen/work/boost-install/include/boost-1_37/boost/serialization/singleton.hpp:124
124	        m_is_destroyed = true;
(gdb) where
#0  ~singleton (this=0x8097d90) at /home/mecklen/work/boost-install/include/boost-1_37/boost/serialization/singleton.hpp:124
#1  0x0807fe2d in ~extended_type_info_typeid (this=0x8097d90) at /home/mecklen/work/boost-install/include/boost-1_37/boost/serialization/extended_type_info_typeid.hpp:80
#2  0x08077f02 in __tcf_7 () at /home/mecklen/work/boost-install/include/boost-1_37/boost/serialization/singleton.hpp:105
#3  0xb7593084 in exit () from /lib/tls/i686/cmov/libc.so.6
#4  0xb757b458 in __libc_start_main () from /lib/tls/i686/cmov/libc.so.6
#5  0x08077ce1 in _start ()
(gdb) cont
Continuing.

Program received signal SIGSEGV, Segmentation fault.
std::_Rb_tree_rebalance_for_erase (__z=0x8098fb8, __header=@0xb7afede0) at ../../../../src/libstdc++-v3/src/tree.cc:337
337	../../../../src/libstdc++-v3/src/tree.cc: No such file or directory.
	in ../../../../src/libstdc++-v3/src/tree.cc
(gdb) where
#0  std::_Rb_tree_rebalance_for_erase (__z=0x8098fb8, __header=@0xb7afede0) at ../../../../src/libstdc++-v3/src/tree.cc:337
#1  0xb7accf93 in boost::serialization::extended_type_info::key_unregister () from /home/mecklen/work/boost-install/lib/boost-1_37/libboost_serialization-gcc42-mt-1_37.so.1.37.0
#2  0xb7acd0ef in boost::serialization::extended_type_info::~extended_type_info () from /home/mecklen/work/boost-install/lib/boost-1_37/libboost_serialization-gcc42-mt-1_37.so.1.37.0
#3  0xb7acda28 in
boost::serialization::detail::extended_type_info_typeid_0::~extended_type_info_typeid_0 ()
from /home/mecklen/work/boost-install/lib/boost-1_37/libboost_serialization-gcc42-mt-1_37.so.1.37.0
#4  0x0807fe3e in ~extended_type_info_typeid (this=0x8097d90) at /home/mecklen/work/boost-install/include/boost-1_37/boost/serialization/extended_type_info_typeid.hpp:80
#5  0x08077f02 in __tcf_7 () at /home/mecklen/work/boost-install/include/boost-1_37/boost/serialization/singleton.hpp:105
#6  0xb7593084 in exit () from /lib/tls/i686/cmov/libc.so.6
#7  0xb757b458 in __libc_start_main () from /lib/tls/i686/cmov/libc.so.6
#8  0x08077ce1 in _start ()
(gdb) 
troy d. straszheim | 8 Oct 19:37

Re: 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,
Jens Weller | 8 Oct 19:52

Re: 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" <troy <at> resophonic.com>
> An: boost-users <at> 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(! 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> 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
troy d. straszheim | 8 Oct 20:00

Re: 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> resophonic.com>
>> An: boost-users <at> 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(! 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> lists.boost.org
>> http://lists.boost.org/mailman/listinfo.cgi/boost-users
> 
Jens Weller | 8 Oct 20:19

Re: serialization 1.36.0 extended_type_info exit issue(s)

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> resophonic.com>
> An: boost-users <at> lists.boost.org
> 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> resophonic.com>
> >> An: boost-users <at> 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(! 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> lists.boost.org
> >> http://lists.boost.org/mailman/listinfo.cgi/boost-users
> > 
> 
> _______________________________________________
> Boost-users mailing list
> Boost-users <at> lists.boost.org
> 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
Robert Ramey | 8 Oct 23:23

Re: serialization1.36.0 extended_type_info exit issue(s)

troy d. straszheim wrote:
> 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.

Just to recap.

a) when an eti (extended_type_info) is created an entry containing its
address is added to a global registry.

b) when an eti record is destroyed, all entries in the global registry
which correspond to this same object (by matching address)
are erased.

c) The global registry consists of two collections.

d) The problem is occuring when when the eti is being destroyed
after the global registry is destroyed.  This occurs when global static
objects are not destroyed in reverse order that they are created.

e) So I added a static boolean flag - is_destroyed to all singleton
objects - including the global eti registry.  This static flag is
set by the destructor of the singleton.

f) Any time an eti record is destroyed, it checks the "is_destroyed"
flag of each global registry and skips the erase operation
if the global registry has been destroyed.

So - if this is not working for anyone, one of the following
must be true:

a) you don't have the lastest copy.(possible)
b) the code is multi-threading and has a race condition
after main() returns.(seems very unlikely to me)
c) my implemenation is flawed(possible - but that's why you testers
get the big bucks!)

So - which is it?

Robert Ramey
troy d. straszheim | 8 Oct 23:04

Re: serialization1.36.0 extended_type_info exit issue(s)

Robert Ramey wrote:
> 
> Just to recap.
> 
(snip)

> a) you don't have the lastest copy.(possible)

I definitely have svn trunk.

> b) the code is multi-threading and has a race condition
> after main() returns.(seems very unlikely to me)

This is all singlethreaded, debug build.

> c) my implemenation is flawed(possible - but that's why you testers
> get the big bucks!)

Would that it were so.

I'll go back and look at all this again with one eye on your recap (thanks).
In case this knocks anything loose, here's the smallest test case I can
produce at the moment.

Classes Base and Derived1 live in a shared library, and a Main.o links to it:

---------------------  Objects.hpp --------------------------

#ifndef OBJECTS_HPP_INCLUDED
#define OBJECTS_HPP_INCLUDED

struct Base
{
   int b;
   virtual ~Base();
   Base(int);
   template <typename Archive> void serialize(Archive& ar, unsigned);
};

struct Derived1 : Base
{
   int d1;
   ~Derived1();
   Derived1(int, int);
   template <typename Archive> void serialize(Archive& ar, unsigned);
};

#endif

---------------------- Objects.cpp -----------------------------

#include "Objects.hpp"
#include <boost/serialization/export.hpp>
#include <boost/serialization/nvp.hpp>
#include <boost/serialization/base_object.hpp>
#include <boost/archive/xml_oarchive.hpp>

namespace bs = boost::serialization;

Base::Base(int i) : b(i) { }
Base::~Base() { }

template <typename Archive>
void
Base::serialize(Archive& ar, unsigned)
{
   ar & bs::make_nvp("b", b);
}
template void Base::serialize(boost::archive::xml_oarchive&, unsigned);

Derived1::Derived1(int i, int j) : d1(i) , Base(j) { }
Derived1::~Derived1() { }

template <typename Archive>
void
Derived1::serialize(Archive& ar, unsigned)
{
   ar & bs::make_nvp("base", bs::base_object<Base>(*this));
   ar & bs::make_nvp("d1", d1);
}
template void Derived1::serialize(boost::archive::xml_oarchive&, unsigned);

BOOST_CLASS_EXPORT(Derived1)

------------------------ (end) -------------------------

Here is the Main.cpp, which is compiled to a .o and then linked
against the .so:

------------------------- Main.cpp -------------------------
#include <boost/shared_ptr.hpp>
#include <boost/serialization/shared_ptr.hpp>
#include <boost/serialization/nvp.hpp>

#include <boost/archive/xml_oarchive.hpp>

#include "Objects.hpp"

int main(int argc, char** argv)
{
   boost::archive::xml_oarchive xoa(std::cout);
   Derived1 d1(9999,8888);
   xoa & boost::serialization::make_nvp("d1", d1);
}

-------------------------------------------------------------

Now, this doesn't crash unless you run it under valgrind
and have valgrind paint free'd memory with 0xAAAAAAA:

% make
rm -f *.o *.so
gcc -g -I. -I/home/troy/Projects/boost/trunk -c Objects.cpp
gcc -shared -o libshlib.so Objects.o -L/home/troy/Projects/boost/trunk/lib
-lboost_serialization-d -lstdc++ -Wl,-rpath,/home/troy/Projects/boost/trunk/lib
gcc -g -I. -I/home/troy/Projects/boost/trunk -c Main.cpp
gcc -o buggy Main.o -L/home/troy/Projects/boost/trunk/lib -lboost_serialization-d -lstdc++
-Wl,-rpath,/home/troy/Projects/boost/trunk/lib -L. -lshlib -Wl,-rpath,`pwd`
valgrind --tool=memcheck --free-fill=AA --malloc-fill=BB ./buggy
==11538== Memcheck, a memory error detector.
==11538== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al.
==11538== Using LibVEX rev 1804, a library for dynamic binary translation.
==11538== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP.
==11538== Using valgrind-3.3.0-Debian, a dynamic binary instrumentation framework.
==11538== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al.
==11538== For more details, rerun with: -v
==11538==
<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<!DOCTYPE boost_serialization>
<boost_serialization signature="serialization::archive" version="5">
<d1 class_id="0" tracking_level="1" version="0" object_id="_0">
         <base class_id="1" tracking_level="0" version="0">
                 <b>8888</b>
         </base>
         <d1>9999</d1>
</d1>
</boost_serialization>

==11538== Invalid read of size 4
==11538==    at 0x410E21B: std::_Rb_tree<boost::serialization::extended_type_info const*,
boost::serialization::extended_type_info const*,
std::_Identity<boost::serialization::extended_type_info const*>,
boost::serialization::detail::key_compare,
std::allocator<boost::serialization::extended_type_info const*>
>::lower_bound(boost::serialization::extended_type_info const* const&) (stl_tree.h:1430)
==11538==    by 0x410E2AE: std::multiset<boost::serialization::extended_type_info const*,
boost::serialization::detail::key_compare,
std::allocator<boost::serialization::extended_type_info const*>
>::lower_bound(boost::serialization::extended_type_info const* const&) (stl_multiset.h:436)
==11538==    by 0x410D3CC: boost::serialization::extended_type_info::key_unregister() (extended_type_info.cpp:90)
==11538==    by 0x410D582: boost::serialization::extended_type_info::~extended_type_info() (extended_type_info.cpp:132)
==11538==    by 0x410ECB6:
boost::serialization::detail::extended_type_info_typeid_0::~extended_type_info_typeid_0() (extended_type_info_typeid.cpp:74)
==11538==    by 0x804DA4F:
boost::serialization::extended_type_info_typeid<Derived1>::~extended_type_info_typeid() (extended_type_info_typeid.hpp:83)
==11538==    by 0x804CFED: __tcf_1 (singleton.hpp:105)
==11538==    by 0x42C5083: exit (in /lib/tls/i686/cmov/libc-2.7.so)
==11538==    by 0x42AD457: (below main) (in /lib/tls/i686/cmov/libc-2.7.so)
==11538==  Address 0x440d080 is 16 bytes inside a block of size 20 free'd
==11538==    at 0x40222EC: operator delete(void*) (vg_replace_malloc.c:342)
==11538==    by 0x410DE38:
__gnu_cxx::new_allocator<std::_Rb_tree_node<boost::serialization::extended_type_info
const*> >::deallocate(std::_Rb_tree_node<boost::serialization::extended_type_info const*>*,
unsigned) (new_allocator.h:97)
==11538==    by 0x410DE6D: std::_Rb_tree<boost::serialization::extended_type_info const*,
boost::serialization::extended_type_info const*,
std::_Identity<boost::serialization::extended_type_info const*>,
boost::serialization::detail::key_compare,
std::allocator<boost::serialization::extended_type_info const*>
>::_M_put_node(std::_Rb_tree_node<boost::serialization::extended_type_info const*>*) (stl_tree.h:371)
==11538==    by 0x410DECD: std::_Rb_tree<boost::serialization::extended_type_info const*,
boost::serialization::extended_type_info const*,
std::_Identity<boost::serialization::extended_type_info const*>,
boost::serialization::detail::key_compare,
std::allocator<boost::serialization::extended_type_info const*>
>::_M_destroy_node(std::_Rb_tree_node<boost::serialization::extended_type_info const*>*) (stl_tree.h:401)
==11538==    by 0x410DF23: std::_Rb_tree<boost::serialization::extended_type_info const*,
boost::serialization::extended_type_info const*,
std::_Identity<boost::serialization::extended_type_info const*>,
boost::serialization::detail::key_compare,
std::allocator<boost::serialization::extended_type_info const*>
>::_M_erase(std::_Rb_tree_node<boost::serialization::extended_type_info const*>*) (stl_tree.h:1325)
==11538==    by 0x410DF62: std::_Rb_tree<boost::serialization::extended_type_info const*,
boost::serialization::extended_type_info const*,
std::_Identity<boost::serialization::extended_type_info const*>,
boost::serialization::detail::key_compare,
std::allocator<boost::serialization::extended_type_info const*> >::~_Rb_tree() (stl_tree.h:592)
==11538==    by 0x410DFBE: std::multiset<boost::serialization::extended_type_info const*,
boost::serialization::detail::key_compare,
std::allocator<boost::serialization::extended_type_info const*> >::~multiset() (stl_multiset.h:91)
==11538==    by 0x410D349: __tcf_0 (singleton.hpp:105)
==11538==    by 0x42C53B0: __cxa_finalize (in /lib/tls/i686/cmov/libc-2.7.so)
==11538==    by 0x40F7CA2: (within /home/troy/Projects/boost/trunk/lib/libboost_serialization-d.so)
==11538==    by 0x413ED0B: (within /home/troy/Projects/boost/trunk/lib/libboost_serialization-d.so)
==11538==    by 0x400DFDE: (within /lib/ld-2.7.so)
==11538==
==11538== Invalid read of size 4
==11538==    at 0x40FCD08: boost::serialization::extended_type_info::get_key() const (extended_type_info.hpp:69)
==11538==    by 0x410DFE2:
boost::serialization::detail::key_compare::operator()(boost::serialization::extended_type_info
const*, boost::serialization::extended_type_info const*) const (extended_type_info.cpp:46)
==11538==    by 0x410E22F: std::_Rb_tree<boost::serialization::extended_type_info const*,
boost::serialization::extended_type_info const*,
std::_Identity<boost::serialization::extended_type_info const*>,
boost::serialization::detail::key_compare,
std::allocator<boost::serialization::extended_type_info const*>
>::lower_bound(boost::serialization::extended_type_info const* const&) (stl_tree.h:1430)
==11538==    by 0x410E2AE: std::multiset<boost::serialization::extended_type_info const*,
boost::serialization::detail::key_compare,
std::allocator<boost::serialization::extended_type_info const*>
>::lower_bound(boost::serialization::extended_type_info const* const&) (stl_multiset.h:436)
==11538==    by 0x410D3CC: boost::serialization::extended_type_info::key_unregister() (extended_type_info.cpp:90)
==11538==    by 0x410D582: boost::serialization::extended_type_info::~extended_type_info() (extended_type_info.cpp:132)
==11538==    by 0x410ECB6:
boost::serialization::detail::extended_type_info_typeid_0::~extended_type_info_typeid_0() (extended_type_info_typeid.cpp:74)
==11538==    by 0x804DA4F:
boost::serialization::extended_type_info_typeid<Derived1>::~extended_type_info_typeid() (extended_type_info_typeid.hpp:83)
==11538==    by 0x804CFED: __tcf_1 (singleton.hpp:105)
==11538==    by 0x42C5083: exit (in /lib/tls/i686/cmov/libc-2.7.so)
==11538==    by 0x42AD457: (below main) (in /lib/tls/i686/cmov/libc-2.7.so)
==11538==  Address 0xaaaaaab2 is not stack'd, malloc'd or (recently) free'd
==11538==
==11538== Process terminating with default action of signal 11 (SIGSEGV)
==11538==  Access not within mapped region at address 0xAAAAAAB2
==11538==    at 0x40FCD08: boost::serialization::extended_type_info::get_key() const (extended_type_info.hpp:69)
==11538==    by 0x410DFE2:
boost::serialization::detail::key_compare::operator()(boost::serialization::extended_type_info
const*, boost::serialization::extended_type_info const*) const (extended_type_info.cpp:46)
==11538==    by 0x410E22F: std::_Rb_tree<boost::serialization::extended_type_info const*,
boost::serialization::extended_type_info const*,
std::_Identity<boost::serialization::extended_type_info const*>,
boost::serialization::detail::key_compare,
std::allocator<boost::serialization::extended_type_info const*>
>::lower_bound(boost::serialization::extended_type_info const* const&) (stl_tree.h:1430)
==11538==    by 0x410E2AE: std::multiset<boost::serialization::extended_type_info const*,
boost::serialization::detail::key_compare,
std::allocator<boost::serialization::extended_type_info const*>
>::lower_bound(boost::serialization::extended_type_info const* const&) (stl_multiset.h:436)
==11538==    by 0x410D3CC: boost::serialization::extended_type_info::key_unregister() (extended_type_info.cpp:90)
==11538==    by 0x410D582: boost::serialization::extended_type_info::~extended_type_info() (extended_type_info.cpp:132)
==11538==    by 0x410ECB6:
boost::serialization::detail::extended_type_info_typeid_0::~extended_type_info_typeid_0() (extended_type_info_typeid.cpp:74)
==11538==    by 0x804DA4F:
boost::serialization::extended_type_info_typeid<Derived1>::~extended_type_info_typeid() (extended_type_info_typeid.hpp:83)
==11538==    by 0x804CFED: __tcf_1 (singleton.hpp:105)
==11538==    by 0x42C5083: exit (in /lib/tls/i686/cmov/libc-2.7.so)
==11538==    by 0x42AD457: (below main) (in /lib/tls/i686/cmov/libc-2.7.so)
==11538==
==11538== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 23 from 1)
==11538== malloc/free: in use at exit: 0 bytes in 0 blocks.
==11538== malloc/free: 25 allocs, 25 frees, 1,265 bytes allocated.
==11538== For counts of detected errors, rerun with: -v
==11538== All heap blocks were freed -- no leaks are possible.
make: *** [buggy] Segmentation fault

What is really odd is that if you change the Main to serialize
through shared-pointer-to-base, things look fine:

------------------ working Main.cpp --------------------------

#include <boost/shared_ptr.hpp>
#include <boost/serialization/shared_ptr.hpp>
#include <boost/serialization/nvp.hpp>
#include <boost/archive/xml_oarchive.hpp>

#include "Objects.hpp"

int main(int argc, char** argv)
{
   boost::archive::xml_oarchive xoa(std::cout);

   boost::shared_ptr<Base> bp(new Derived1(777,666));
   xoa & boost::serialization::make_nvp("ptr", bp);
}

--------------------- output of the run -----------------------

% make
rm -f *.o *.so
gcc -g -I. -I/home/troy/Projects/boost/trunk -c Objects.cpp
gcc -shared -o libshlib.so Objects.o -L/home/troy/Projects/boost/trunk/lib
-lboost_serialization-d -lstdc++ -Wl,-rpath,/home/troy/Projects/boost/trunk/lib
gcc -g -I. -I/home/troy/Projects/boost/trunk -c Main.cpp
gcc -o buggy Main.o -L/home/troy/Projects/boost/trunk/lib -lboost_serialization-d -lstdc++
-Wl,-rpath,/home/troy/Projects/boost/trunk/lib -L. -lshlib -Wl,-rpath,`pwd`
valgrind --tool=memcheck --free-fill=AA --malloc-fill=BB ./buggy
==11556== Memcheck, a memory error detector.
==11556== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al.
==11556== Using LibVEX rev 1804, a library for dynamic binary translation.
==11556== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP.
==11556== Using valgrind-3.3.0-Debian, a dynamic binary instrumentation framework.
==11556== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al.
==11556== For more details, rerun with: -v
==11556==
<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<!DOCTYPE boost_serialization>
<boost_serialization signature="serialization::archive" version="5">
<ptr class_id="0" tracking_level="0" version="1">
         <pxvoid boost::archive::detail::basic_oarchive::register_basic_serializer(const boost::archive::detail::basic_oserializer&)
  class_id="2" class_name="Derived1" tracking_level="1" version="0" object_id="_0">
                 <base class_id="1" tracking_level="1" version="0" object_id="_1">
                         <b>666</b>
                 </base>
                 <d1>777</d1>
         </px>
</ptr>
</boost_serialization>

==11556==
==11556== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 23 from 1)
==11556== malloc/free: in use at exit: 0 bytes in 0 blocks.
==11556== malloc/free: 32 allocs, 32 frees, 1,409 bytes allocated.
==11556== For counts of detected errors, rerun with: -v
==11556== All heap blocks were freed -- no leaks are possible.

----------------------------------------------------------------

That's all I've got for now...

-t
Robert Ramey | 9 Oct 01:37

Re: serialization1.36.0 extended_type_info exit issue(s)

troy d. straszheim wrote:
> Robert Ramey wrote:
>>
>> Just to recap.
>>
> (snip)
>
>> a) you don't have the lastest copy.(possible)
>
> I definitely have svn trunk.
>
>> b) the code is multi-threading and has a race condition
>> after main() returns.(seems very unlikely to me)
>
> This is all singlethreaded, debug build.
>
>> c) my implemenation is flawed(possible - but that's why you testers
>> get the big bucks!)
>
> Would that it were so.
>

> Now, this doesn't crash unless you run it under valgrind
> and have valgrind paint free'd memory with 0xAAAAAAA:
>> ==11538== Invalid read of size 4
> ==11538==    at 0x410E21B:
> std::_Rb_tree<boost::serialization::extended_type_info const*,
> boost::serialization::extended_type_info const*,
> std::_Identity<boost::serialization::extended_type_info const*>,
> boost::serialization::detail::key_compare,
> std::allocator<boost::serialization::extended_type_info const*>
> >::lower_bound(boost::serialization::extended_type_info const*
> const&) (stl_tree.h:1430) ==11538==    by 0x410E2AE:
> std::multiset<boost::serialization::extended_type_info const*,
> boost::serialization::detail::key_compare,
> std::allocator<boost::serialization::extended_type_info const*>
> >::lower_bound(boost::serialization::extended_type_info const*
> const&) (stl_multiset.h:436) ==11538==    by 0x410D3CC:
> boost::serialization::extended_type_info::key_unregister()
> (extended_type_info.cpp:90) ==11538==    by 0x410D582:
> boost::serialization::extended_type_info::~extended_type_info()

...

Here is the code that provokes the error

BOOST_SERIALIZATION_DECL(void)

extended_type_info::key_register(const char *key) {

assert(NULL != key);

m_key = key;

singleton<detail::ktmap>::get_mutable_instance().insert(this);

}

BOOST_SERIALIZATION_DECL(void)

extended_type_info::key_unregister() {

assert(NULL != m_key);

if(! singleton<detail::ktmap>::is_destroyed()){

detail::ktmap & x = singleton<detail::ktmap>::get_mutable_instance();

detail::ktmap::iterator start = x.lower_bound(this);    ///////// line # 
90 - problem is here

detail::ktmap::iterator end = x.upper_bound(this);

assert(start != end);

// remove entry in map which corresponds to this type

do{

if(this == *start)

x.erase(start++);

else

++start;

}while(start != end);

}

m_key = NULL;

}

So trap on this line and verify that 
singleton<detail::ktmap>::is_destroyed() is not true

then trap on the destructor of  singleton<detail::ktmap>::is_destroyed() to 
verify that

m_is_destroyed is in fact getting set when the table is destroyed.

Robert Ramey
troy d. straszheim | 9 Oct 02:17

Re: serialization1.36.0 extended_type_info exit issue(s)

Robert Ramey wrote:
> 
> So trap on this line and verify that 
> singleton<detail::ktmap>::is_destroyed() is not true
> 
> then trap on the destructor of  singleton<detail::ktmap>::is_destroyed() to 
> verify that
> 
> m_is_destroyed is in fact getting set when the table is destroyed.

The detail::ktmap is getting destroyed *before* the singleton
that holds it.  So is_destroyed() returns false... but that's wrong.
Does the standard guarantee that the static T that is inside
singleton<T>::get_instance() will be destroyed *after* the singleton<T>
itself?  It seems like the compiler could figure out that the singleton<T>
never actually talks to the static T inside get_instance(), ie. it looks
like it would be pretty easy to figure out that use() doesn't do anything
and get rid of it entirely.

I put together a fix which works... not sure what I think of it.
Singletons inherit from a singleton_instance class that notifies the singleton (!)
of its destruction.  Looks like this:

in extended_type_info.cpp, detail::ktmap is no longer a typedef:

   struct ktmap : std::multiset<const extended_type_info*, key_compare>,
		 singleton_instance<ktmap>
   { };

and in singleton.hpp, you've got this:

template <class T>
class singleton_instance;

template <class T>
class singleton : public singleton_module
{
     static bool m_is_destroyed;
     BOOST_DLLEXPORT static T & instance;
     // include this to provoke instantiation at pre-execution time
     static void use(T const &) {}

     BOOST_DLLEXPORT static T & get_instance() {
       static T t;
         // refer to instance, causing it to be instantiated (and
         // initialized at startup on working compilers)
         assert(! m_is_destroyed);
         use(instance);
         return t;
     }

     BOOST_DLLEXPORT static void destroy() { m_is_destroyed = true; }

public:
     BOOST_DLLEXPORT static T & get_mutable_instance(){
         assert(! is_locked());
         return get_instance();
     }
     BOOST_DLLEXPORT static const T & get_const_instance(){
         return get_instance();
     }
     BOOST_DLLEXPORT static bool is_destroyed(){
       return m_is_destroyed;
     }
     ~singleton(){
       m_is_destroyed = true;
     }
   friend class singleton_instance<T>;
};

template<class T>
BOOST_DLLEXPORT T & singleton<T>::instance = singleton<T>::get_instance();

template<class T> bool singleton<T>::m_is_destroyed = false;

template <class T>
class singleton_instance
{
public:
   ~singleton_instance() { singleton<T>::destroy(); }
};

What do you make of all this?

-t
Robert Ramey | 9 Oct 06:16

Re: serialization1.36.0 extended_type_info exit issue(s)

OK - I see the problem now - good work.  I'm not sold on your
fix but I think this can be addressed.

I'll make the patch, test here, and check it into the trunk for testing.

Robert Ramey