[Boost-users] boost 1.39 serialization via base pointer ok on gcc, but crashes on AIX V10.1

Subject: [Boost-users] boost 1.39 serialization via base pointer ok on gcc, but crashes on AIX V10.1
From: Avi Bahra (avibahra_at_[hidden])
Date: 2009-07-23 09:13:04

Take the following small self contained example.
This compiles and runs without any problems on gcc 4.2.1 on SUSE Linux.

However on AIX v10.1 compiler, you see the following on compile:

"/s1a/emos_esuite/emos_data/sms/boost_1_39_0/boost/archive/detail/oserializer.hpp",
line 538.5: 1540-2400 (W) "boost::serialization::STATIC_WARNING" is
undefined.  The delete operator will not call a destructor.
"/s1a/emos_esuite/emos_data/sms/boost_1_39_0/boost/archive/detail/oserializer.hpp",
line 530.13: 1540-0700 (I) The previous message was produced while
processing
"boost::archive::save<boost::archive::text_oarchive,Defs>(text_oarchive
"/s1a/emos_esuite/emos_data/sms/boost_1_39_0/boost/archive/detail/common_oarchive.hpp",
line 64.9: 1540-0700 (I) The previous message was produced while processing
"boost::archive::detail::common_oarchive<boost::archive::text_oarchiv.
"/s1a/emos_esuite/emos_data/sms/boost_1_39_0/boost/archive/basic_text_oarchive.hpp",
line 75.13: 1540-0700 (I) The previous message was produced while processing
"boost::archive::basic_text_oarchive<boost::archive::text_oarchive>::sa
"/s1a/emos_esuite/emos_data/sms/boost_1_39_0/boost/archive/detail/interface_oarchive.hpp",
line 64.21: 1540-0700 (I) The previous message was produced while processing
"boost::archive::detail::interface_oarchive<boost::archive::text_.
"src/TestSerialisation2.cpp", line 86.20: 1540-0700 (I) The previous message
was produced while processing "main()".
vacpp.compile.c++ bin/vacpp/debug/src/TestSerialisation.o

   When the program is run, the following is produced by the debugger:

Can't read type info for "basic_pointer_oserializer": Expecting mangled
name, and didn't find one.
Can't read type info for "basic_pointer_iserializer": Expecting mangled
name, and didn't find one.
Can't read type info for
"singleton<boost__archive__detail__<unnamed>__guid_initializer<RepeatDate>
>": Expecting ":", and didn't find one.
Can't read type info for
"singleton_wrapper<boost__archive__detail__<unnamed>__guid_initializer<RepeatDate>
>": Expecting ":", and didn't find one.
Can't read type info for "error_info_container": Expecting mangled name, and
didn't find one.
Can't read type info for "init_guid<RepeatDate>": Expecting ":", and didn't
find one.

   it then throw an exception: archive_exception::unregistered_cast

   This is because the it thinks that Base/Derived class relationship has
not been
   registered. (i.e RepeatBase/RepeatDerived in the enclosed example).
   It appears that:

       ar & boost::serialization::base_object<RepeatBase>(*this);

   is not registering the base/derived relationship on AIX.

   The actual point in the code where is throws an exception is >>>>>>>>>:

            // convert pointer to more derived type. if this is thrown
             // it means that the base/derived relationship hasn't be
registered
             vp = serialization::void_downcast(
                 *true_type,
                 *this_type,
                 static_cast<const void *>(&t)
             );
             if(NULL == vp){
                 boost::serialization::throw_exception(
 >>>>>>
archive_exception(archive_exception::unregistered_cast)
                 );
             }

   In the debugger variables true_type and this_type are of type
   boost::serialization::extended_type_info

   true_type:
m_type_info_key    unsigned int const 0x1100121b8  0x00000001 (1)
m_key            $string const *    0x1100121c0  0x1000b9748 ->
"RepeatDerived"

  this_type:
m_type_info_key    unsigned int const  0x110012a40        0x00000001 (1)
m_key            $string const *        0x110012a48        0x00000000

  It looks like the m_key data member of this_type is empty,
  I expected "RepeatBase"

  Has any one else hit a similar problem, where on one platform its ok
  and another it crashes ? Are there any workarounds I could try ?

-- 
  Best regards,
Ta,
   Avi