Boost logo

Boost Users :

From: Markus Bernhardt (Markus.Bernhardt_at_[hidden])
Date: 2007-06-29 07:21:56


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi everyone,

I'm using serialization for quite a while now. Everything worked for me.
 Now I added some classes to serialization and one off my classes causes
an assertion. This happens with 1.32.0 and 1.34.0. I'm quite sure my
code is broken, but I can't find it.

Therefore I was debugging and it looks weird.

1. OS: Solaris 10
   CC: Sun C++ 5.8 Patch 121018-10 2007/02/21 (latest patch level)
   Reproducable under Sparc and x86

2. The programm crashes on startup:

(dbx) where
current thread: t_at_1
  [1] __lwp_kill(0x1, 0x6, 0xfffffe8200db3500, 0x3, 0xfffffd7fffdff2a0,
0xfffffd7fff3c73a0), at 0xfffffd7ffd7fe81a
  [2] _thr_kill(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfffffd7ffd7f9803
  [3] raise(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfffffd7ffd7a7849
  [4] abort(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfffffd7ffd78a7e0
  [5] __assert(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfffffd7ffd78aa6e
=>[6] boost::serialization::detail::tkmap::insert(eti =
0xfffffd7fff357540), line 78 in "extended_type_info.cpp"
  [7] boost::serialization::extended_type_info::self_register(this =
0xfffffd7fff357540), line 231 in "extended_type_info.cpp"
  [8] boost::serialization::detail::extended_type_info_typeid_1<const
de::scmb::bm::core::SyncedRedoableWriteCommand<de::scmb::bm::core::Instance>
>::extended_type_info_typeid_1(this = 0xfffffd7fff357540), line 77 in
"extended_type_info_typeid.hpp"
  [9] boost::serialization::detail::extended_type_info_typeid_1<const
de::scmb::bm::core::SyncedRedoableWriteCommand<de::scmb::bm::core::Instance>
>::get_instance(), line 96 in "extended_type_info_typeid.hpp"
  [10]
boost::archive::detail::pointer_oserializer<de::scmb::bm::core::SyncedRedoableWriteCommand<de::scmb::bm::core::Instance>,boost::archive::binary_oarchive>::pointer_oserializer(this
= 0xfffffd7fff3576b8), line 234 in "oserializer.hpp"
  [11] __SLIP.INIT_E(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfffffd7fff2db3bf
  [12] __STATIC_CONSTRUCTOR(), line 197 in "oserializer.hpp"
  [13] __cplus_fini_at_exit(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at
0xfffffd7fff320fd2
  [14] call_init(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfffffd7fff3d278a
  [15] setup(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfffffd7fff3d1491
  [16] _setup(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfffffd7fff3ded6f
  [17] _rt_boot(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfffffd7fff3c717f

3. The assertion is: assert(lookup(eti) == m_self->m_map.end());

(dbx) print -r lookup(eti)
lookup(eti) = {
    _Rb_tree_iterator<const
boost::serialization::extended_type_info*,std::_Const_traits<const
boost::serialization::extended_type_info*>
>::_Rb_tree_base_iterator::_M_node = (nil)
}

(dbx) print -r m_self->m_map.end()
m_self->m_map.end() = {
    _Rb_tree_iterator<const
boost::serialization::extended_type_info*,std::_Const_traits<const
boost::serialization::extended_type_info*>
>::_Rb_tree_base_iterator::_M_node = (nil)
}

Why the assertion is triggered ???
Both sides are "(nil)".

4. To get a better understanding I added a trace to extended_type_info.cpp:

    insert(const extended_type_info * eti){
        if(NULL == m_self){
            static tkmap instance;
            m_self = & instance;
        }

        // markus
        std::cout
          << eti->m_type_info_key
          << ": "
          << &(eti->m_type_info_key)
          << std::endl;

        // make sure that attempt at registration is done only once
        assert(lookup(eti) == m_self->m_map.end());
        m_self->m_map.insert(eti);
    }

The result confuses me even more:

(dbx) run
Running: bm_instd
(process id 22999)
extended_type_info_typeid: 0xfffffd7ffe5467b8
extended_type_info_typeid: 0xfffffd7ffe546808
extended_type_info_typeid: 0xfffffd7ffe546858
extended_type_info_typeid: 0xfffffd7ffe5468a8
extended_type_info_typeid: 0xfffffd7ffe5468f8
extended_type_info_typeid: 0xfffffd7ffe546948
extended_type_info_typeid: 0xfffffd7ffe546998
extended_type_info_typeid: 0xfffffd7ffe5469e8
extended_type_info_typeid: 0xfffffd7ffe546a38
extended_type_info_typeid: 0xfffffd7ffe546a88
extended_type_info_typeid: 0xfffffd7ffe546ad8
extended_type_info_typeid: 0xfffffd7ffe546b28
extended_type_info_typeid: 0xfffffd7ffe546b78
extended_type_info_typeid: 0xfffffd7ffe546bc8
extended_type_info_typeid: 0xfffffd7ffe546c18
extended_type_info_typeid: 0xfffffd7ffe546c68
extended_type_info_typeid: 0xfffffd7ffe546cb8
extended_type_info_typeid: 0xfffffd7ffe54b2d8
extended_type_info_typeid: 0xfffffd7ffe54b750
extended_type_info_typeid: 0xfffffd7ffe54bc58
extended_type_info_typeid: 0xfffffd7ffe54b700
extended_type_info_typeid: 0xfffffd7ffe54b970
extended_type_info_typeid: 0xfffffd7ffe54bac0
extended_type_info_typeid: 0xfffffd7ffe54c270
extended_type_info_typeid: 0xfffffd7ffe54bba8
extended_type_info_typeid: 0xfffffd7ffe54d4e8
extended_type_info_typeid: 0xfffffd7ffe54d180
extended_type_info_typeid: 0xfffffd7ffe54e5a8
extended_type_info_typeid: 0xfffffd7ffe54e5f8
extended_type_info_typeid: 0xfffffd7ffe54e648
extended_type_info_typeid: 0xfffffd7ffe550778
extended_type_info_typeid: 0xfffffd7ffe551870
extended_type_info_typeid: 0xfffffd7ffe5521d0
extended_type_info_typeid: 0xfffffd7ffe5529a8
extended_type_info_typeid: 0xfffffd7ffe553180
extended_type_info_typeid: 0xfffffd7ffe553958
extended_type_info_typeid: 0xfffffd7ffe554130
extended_type_info_typeid: 0xfffffd7ffe554908
extended_type_info_typeid: 0xfffffd7ffe5550e0
extended_type_info_typeid: 0xfffffd7ffe5558b8
extended_type_info_typeid: 0xfffffd7ffe556090
extended_type_info_typeid: 0xfffffd7ffe556868
extended_type_info_typeid: 0xfffffd7ffe5581f0
extended_type_info_typeid: 0xfffffd7ffe558670
extended_type_info_typeid: 0xfffffd7ffe558238
extended_type_info_typeid: 0xfffffd7ffe558a48
extended_type_info_typeid: 0xfffffd7ffe558ac0
extended_type_info_typeid: 0xfffffd7ffe559108
extended_type_info_typeid: 0xfffffd7fff357598
extended_type_info_typeid: 0xfffffd7fff357548
Assertion failed: lookup(eti) == m_self->m_map.end(), file
libs/serialization/src/extended_type_info.cpp, line 78
t_at_1 (l_at_1) signal ABRT (Abbrechen) in __lwp_kill at 0xfffffd7ffd7fe81a
0xfffffd7ffd7fe81a: __lwp_kill+0x000a: jae __lwp_kill+0x18
[ 0xfffffd7ffd7fe828, .+0xe ]
Current function is boost::serialization::detail::tkmap::insert
   78 assert(lookup(eti) == m_self->m_map.end());

If I understand that right, it looks like
extended_type_info_typeid: 0xfffffd7fff357548
is already in the map. How can that be?

I think I'm completely missing the point at the moment. Can anyone
suggest me where to look for the problem?

Any comments are greatly appreciated.

    - markus

- --
Software Consulting
Markus Bernhardt GmbH
Spieljochstr. 34
81825 München

Fon: +49-89-420903-14
Fax: +49-89-420903-20
www: http://www.scmb.de

Geschäftsführung Markus Bernhardt
Handelsregister AG München HRB 125966
USt-Id DE201885231

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGhOtUdnooMonJSYkRAnhWAJ0cQPXyO7IZ2g6X5HNG55CzqFppBACfZDU6
3XpX5bmP0yqrFTrAyntWBIs=
=0SAJ
-----END PGP SIGNATURE-----


Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net