[serialization] Latest changes broke module-singleton
Hi all, I believe the latest changes to the serialization library in trunk broke the encapsulation of module singletons. Module singletons are now accessed across module boundaries (i.e data stored in a different module are looked up locally). A polymorphic class registered using BOOST_CLASS_EXPORT() gets registered in the archive's basic_serializer_map, which is stored in a module-singleton. Ok so far. Now, if this type is serialized by a different module via its base class (which is the usual scenario for us, as all serialization code lives in one place) this code tries to look up the type in the archive's module-singleton (basic_serializer_map) of its own module (I saw this for instance at boost/archive/detail/oserializer.npp, line 413). But the data is stored not there but in the original module, where the type is implemented. As a result the assertion at libs/serialization/src/basic_initializer_map.cpp, line 56 fires. Anything I could do about this? Regards Hartmut
I think I fixed this and checked in the change a couple of hours ago. I broke this while fixing something else. Now all serializer maps should be instanticiated only by the serialization DLL. Let me know if there's still a problem. Let me know if it's not fixed. Hartmut Kaiser wrote:
Hi all,
I believe the latest changes to the serialization library in trunk broke the encapsulation of module singletons. Module singletons are now accessed across module boundaries (i.e data stored in a different module are looked up locally).
A polymorphic class registered using BOOST_CLASS_EXPORT() gets registered in the archive's basic_serializer_map, which is stored in a module-singleton. Ok so far. Now, if this type is serialized by a different module via its base class (which is the usual scenario for us, as all serialization code lives in one place) this code tries to look up the type in the archive's module-singleton (basic_serializer_map) of its own module (I saw this for instance at boost/archive/detail/oserializer.npp, line 413). But the data is stored not there but in the original module, where the type is implemented.
As a result the assertion at libs/serialization/src/basic_initializer_map.cpp, line 56 fires.
Anything I could do about this?
Regards Hartmut
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
I think I fixed this and checked in the change a couple of hours ago. I broke this while fixing something else. Now all serializer maps should be instanticiated only by the serialization DLL. Let me know if there's still a problem.
Let me know if it's not fixed.
Currently I'm getting: libs\serialization\src\binary_iarchive.cpp(17) : fatal error C1083: Cannot open include file: 'boost/archive/impl/archive_serializer_map.ipp': No such file or directory Regards Hartmut
Hartmut Kaiser wrote:
Hi all,
I believe the latest changes to the serialization library in trunk broke the encapsulation of module singletons. Module singletons are now accessed across module boundaries (i.e data stored in a different module are looked up locally).
A polymorphic class registered using BOOST_CLASS_EXPORT() gets registered in the archive's basic_serializer_map, which is stored in a module-singleton. Ok so far. Now, if this type is serialized by a different module via its base class (which is the usual scenario for us, as all serialization code lives in one place) this code tries to look up the type in the archive's module-singleton (basic_serializer_map) of its own module (I saw this for instance at boost/archive/detail/oserializer.npp, line 413). But the data is stored not there but in the original module, where the type is implemented.
As a result the assertion at libs/serialization/src/basic_initializer_map.cpp, line 56 fires.
Anything I could do about this?
Regards Hartmut
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
I think I fixed this and checked in the change a couple of hours ago. I broke this while fixing something else. Now all serializer maps should be instanticiated only by the serialization DLL. Let me know if there's still a problem.
Let me know if it's not fixed.
Currently I'm getting:
libs\serialization\src\binary_iarchive.cpp(17) : fatal error C1083: Cannot open include file: 'boost/archive/impl/archive_serializer_map.ipp': No such file or directory
Compiles fine now. Thanks! Now, at runtime I'm getting a pure virtual function call assertion here: libs/serialization/src/void_cast.cpp, line 239 (yes, it's still the same delete, *sigh*. If I comment out the 'delete vc;', things work again. So the module-singleton issue seems to be fixed. Regards Hartmut
Regards Hartmut
Hartmut Kaiser wrote:
Hi all,
I believe the latest changes to the serialization library in trunk broke the encapsulation of module singletons. Module singletons are now accessed across module boundaries (i.e data stored in a different module are looked up locally).
A polymorphic class registered using BOOST_CLASS_EXPORT() gets registered in the archive's basic_serializer_map, which is stored
in
a module-singleton. Ok so far. Now, if this type is serialized by a different module via its base class (which is the usual scenario for us, as all serialization code lives in one place) this code tries to look up the type in the archive's module-singleton (basic_serializer_map) of its own module (I saw this for instance at boost/archive/detail/oserializer.npp, line 413). But the data is stored not there but in the original module, where the type is implemented.
As a result the assertion at libs/serialization/src/basic_initializer_map.cpp, line 56 fires.
Anything I could do about this?
Regards Hartmut
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Hartmut Kaiser wrote:
Now, at runtime I'm getting a pure virtual function call assertion here: libs/serialization/src/void_cast.cpp, line 239 (yes, it's still the same delete, *sigh*.
This is starting to stress me out. Turns out I had a few "pure virtual function call" assertions related to the usage of virtual functions called from destructors. The showed up in a few of the serialization library tests but I thought I fixed them all - at least all the tests pass now (except for one unrelated? test). In my current copy, line 239 isn't an "assert" statement but rather a "delete vc". Before it was invoking an assertion in extended_type_info comparison - server levels down. Do you have any more information you could give me? Robert Ramey
Robert,
Hartmut Kaiser wrote:
Now, at runtime I'm getting a pure virtual function call assertion here: libs/serialization/src/void_cast.cpp, line 239 (yes, it's still the same delete, *sigh*.
This is starting to stress me out. Turns out I had a few "pure virtual function call" assertions related to the usage of virtual functions called from destructors. The showed up in a few of the serialization library tests but I thought I fixed them all - at least all the tests pass now (except for one unrelated? test).
In my current copy, line 239 isn't an "assert" statement but rather a "delete vc". Before it was invoking an assertion in extended_type_info comparison - server levels down.
Your latest changes seem to have fixed my issues. Everything started to work again. Thanks! Regards Hartmut
Well, I'm still suffering here. My two new tests for DLLS are failing with gcc and I can't seem to get debug them with my cygwin setup. So if someone would like to look into that I would be greatful. Also, fixing some other bugs broke test_no_rtti and I having a heck of time fixing that. This is a logical problem I'm working on and I don't think anyone can help me with so you can all relax. Robert Ramey Hartmut Kaiser wrote:
Robert,
Hartmut Kaiser wrote:
Now, at runtime I'm getting a pure virtual function call assertion here: libs/serialization/src/void_cast.cpp, line 239 (yes, it's still the same delete, *sigh*.
This is starting to stress me out. Turns out I had a few "pure virtual function call" assertions related to the usage of virtual functions called from destructors. The showed up in a few of the serialization library tests but I thought I fixed them all - at least all the tests pass now (except for one unrelated? test).
In my current copy, line 239 isn't an "assert" statement but rather a "delete vc". Before it was invoking an assertion in extended_type_info comparison - server levels down.
Your latest changes seem to have fixed my issues. Everything started to work again.
Thanks! Regards Hartmut
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
participants (2)
-
Hartmut Kaiser -
Robert Ramey