[serialization][thread] possible regressions? (was: [1.45.0] Beta 1 available from SourceForge)
I don't know whether this is a serialization issue or a thread issue. Robert, Anthony, can you two weigh in? Eric On 11/11/2010 6:32 AM, Ruediger Berlich wrote:
Hi again,
here is an update: I have now also tested the behaviour below ("pure virtual method called; terminate called without an active exception" -> related to Boost.Serialization) with Boost 1.44 and see the same problem. This does not happen with 1.43.
Anyway, I thought it might be important to know that whatever causes this wasn't introduced with 1.45 but 1.44 (and of course I might be doing something wrong which only triggers now due to 1.44's changes in the serialization library).
Thanks and Best Regards, Ruediger
Ruediger Berlich wrote:
Dear all, here are a few experiences with the beta:
Beman Dawes wrote: [...]
Please download the beta, give it a try, and report any problems you encounter.
Platform: ========= Kubuntu 10.10 64 bit, g++ 4.4.5
Compilation: ============ Runs mostly smoothely, albeit with many warnings of the type:
[...] libs/program_options/src/parsers.cpp:233: instantiated from here ./boost/function/function_base.hpp:321: warning: dereferencing type-punned pointer will break strict-aliasing rules ./boost/function/function_base.hpp:325: warning: dereferencing type-punned pointer will break strict-aliasing rules [...]
This is not a new situation and has been there with many prior versions. It happens in different components.
Compiling a complex application =============================== (The Geneva library's trunk version, close to version 0.85, see http://launchpad.net/geneva ; depends on probably a dozen different boost libraries)
In order to get it to compile I hat to make a single change: I had to add "#include <boost/serialization/nvp.hpp>" prior to the inclusion of the date_time libraries in a single file (out of some 65 headers, some of which also include date_time), or else I would get messages of the type
/opt/boost145/include/boost/date_time/gregorian/greg_serialize.hpp: In function ‘void boost::serialization::save(Archive&, const boost::gregorian::date&, unsigned int)’: /opt/boost145/include/boost/date_time/gregorian/greg_serialize.hpp:58: error: there are no arguments to ‘make_nvp’ that depend on a template parameter, so a declaration of ‘make_nvp’ must be available
I _do_ serialize date_time objects in my application. This is new with Boost 1.45 (compared with 1.43).
Running the application =======================
When running the application in serial. multithreaded or networked mode (Geneva does distributed parametric optimization, but also allows multithreaded optimization and has a serial mode for debugging), I get the error:
[...] 1000: 4.99999977648258e-05 End of optimization reached Done ... pure virtual method called terminate called without an active exception Aborted
"Done" is printed at the end of main(), so there are only some singletons left to clean up, one of which stems from the Boost.Serialization library, AFAIK.
Running the application in gdb yields:
/********************************************************/ (gdb) up #1 0x00007ffff40726b0 in abort () at abort.c:92 92 abort.c: No such file or directory. in abort.c (gdb) up #2 0x00007ffff49126bd in __gnu_cxx::__verbose_terminate_handler() () from /usr/lib/libstdc++.so.6 (gdb) up #3 0x00007ffff4910906 in ?? () from /usr/lib/libstdc++.so.6 (gdb) up #4 0x00007ffff4910933 in std::terminate() () from /usr/lib/libstdc++.so.6 (gdb) up #5 0x00007ffff491128f in __cxa_pure_virtual () from #/usr/lib/libstdc++.so.6 (gdb) up #6 0x00007ffff4fc1f16 in
boost::serialization::void_cast_detail::void_caster::operator<(boost::serialization::void_cast_detail::void_caster
const&) const () from /opt/boost145/lib/libboost_serialization.so.1.45.0 (gdb) up #7 0x00007ffff4fc282d in
boost::serialization::void_cast_detail::void_caster::recursive_unregister()
const () from /opt/boost145/lib/libboost_serialization.so.1.45.0 (gdb) up #8 0x00007ffff4fc2f27 in
boost::serialization::void_cast_detail::void_caster_shortcut::~void_caster_shortcut()
() from /opt/boost145/lib/libboost_serialization.so.1.45.0 (gdb) up #9 0x00007ffff4fc289f in
boost::serialization::void_cast_detail::void_caster::recursive_unregister()
const () from /opt/boost145/lib/libboost_serialization.so.1.45.0 (gdb) up #10 0x00007ffff72ad64f in
boost::serialization::void_cast_detail::void_caster_primitive<Gem::Geneva::GPersonalityTraits,
Gem::Geneva::GObject>::~void_caster_primitive (this=0x7ffff7bb7e80, __in_chrg=<value optimized out>) at /opt/boost145/include/boost/serialization/void_cast.hpp:198 198 recursive_unregister(); (gdb) up #11 0x00007ffff72ad7be in
boost::serialization::detail::singleton_wrapper<boost::serialization::void_cast_detail::void_caster_primitive<Gem::Geneva::GPersonalityTraits,
Gem::Geneva::GObject> >::~singleton_wrapper ( this=0x7ffff7bb7e80, __in_chrg=<value optimized out>) at /opt/boost145/include/boost/serialization/singleton.hpp:111 111 m_is_destroyed = true; (gdb) up #12 0x00007ffff40748c0 in __cxa_finalize (d=0x7ffff7baa2d0) at cxa_finalize.c:56 56 cxa_finalize.c: No such file or directory. in cxa_finalize.c (gdb) up #13 0x00007ffff7016366 in __do_global_dtors_aux () from /home/rberlich/geneva-build/src/geneva/libgemfony-geneva.so.0.8.5rc0 (gdb) up #14 0x0000000000000000 in ?? () (gdb) up Initial frame selected; you cannot go up. /********************************************************/
Gem::Geneva::GPersonalityTraits is a purely virtual class, marked as such with the following code: "BOOST_SERIALIZATION_ASSUME_ABSTRACT(Gem::Geneva::GPersonalityTraits)" . GObject is the base class of all optimization-related classes.
The exact same code compiles and runs fine with Boost 1.43, the last version I have been using excessively. I cannot really comment on Boost 1.44 , but would be happy to try if it helps.
Note that the above problem does not seem to have any influence on the results of the program. The problems only appear at the very end of the execution, when various singletons get destroyed.
Best Regards, Ruediger
-- Eric Niebler BoostPro Computing http://www.boostpro.com
Eric Niebler <eric@boostpro.com> writes:
I don't know whether this is a serialization issue or a thread issue. Robert, Anthony, can you two weigh in?
Looks like a serialization problem to me. Anthony -- Author of C++ Concurrency in Action http://www.stdthread.co.uk/book/ just::thread C++0x thread library http://www.stdthread.co.uk Just Software Solutions Ltd http://www.justsoftwaresolutions.co.uk 15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK. Company No. 5478976
Anthony Williams wrote:
Eric Niebler <eric@boostpro.com> writes:
I don't know whether this is a serialization issue or a thread issue. Robert, Anthony, can you two weigh in?
Looks like a serialization problem to me.
I would agree - but its hard to reproduce from here. I don't see this as quick fix - it would require some time and help from the person who can actually reproduce it. Robert Ramey
On 11/11/2010 1:41 PM, Robert Ramey wrote:
Anthony Williams wrote:
Eric Niebler <eric@boostpro.com> writes:
I don't know whether this is a serialization issue or a thread issue. Robert, Anthony, can you two weigh in?
Looks like a serialization problem to me.
I would agree - but its hard to reproduce from here. I don't see this as quick fix - it would require some time and help from the person who can actually reproduce it.
Thanks, Robert. This is now https://svn.boost.org/trac/boost/ticket/4842 Ruediger, anything you can do to help Robert with this one would be much appreciated. -- Eric Niebler BoostPro Computing http://www.boostpro.com
Robert, all, I'm of course happy to help, e.g. try out fixes you propose. The code is available at http://www.launchpad.net/geneva for you to look at, if you want. Click on "View the branch content". The code in question is in the include/geneva and src/geneva subdirectories. I have, just for kicks, commented out the BOOST_SERIALIZATION_ASSUME_ABSTRACT in http://bazaar.launchpad.net/~gemfony/geneva/trunk/annotate/head%3A/include/g... plus the BOOST_CLASS_EXPORT(Gem::Geneva::GPersonalityTraits) in http://bazaar.launchpad.net/~gemfony/geneva/trunk/annotate/head%3A/src/genev... My understanding is that, with gcc, Boost.Serialization is able to detect by itself that GPersonalityTraits is purely virtual, and that BOOST_CLASS_EXPORT doesn't make a difference anyway for a class that cannot be instantiated directly. However, the error message at the end of the program execution remains the same. I am also pretty confident that serialization itself is unaffected (during the program's runtime), since server and client can communicate and the program correctly converges towards the minimum of a toy optimization problem (i.e. the right data is exchanged). Best Regards, Ruediger P.S.: Please do expect a few hours delay between any proposed fix and my answer, given that Robert is in the US and I am in Europe. Robert Ramey wrote:
Anthony Williams wrote:
Eric Niebler <eric@boostpro.com> writes:
I don't know whether this is a serialization issue or a thread issue. Robert, Anthony, can you two weigh in?
Looks like a serialization problem to me.
I would agree - but its hard to reproduce from here. I don't see this as quick fix - it would require some time and help from the person who can actually reproduce it.
Robert Ramey
Hi, yet another update: Geneva also comprises unit tests for the (de-)serialization of instantiable classes in different serialization modes (XML, binary, text). Apart from the already known error pure virtual method called terminate called without an active exception Aborted these tests complete without problems. This and the fact that 1.43 didn't have these problems makes me confident that the error message isn't caused by the way in which I use the serialization library (which, albeit quite extensive, doesn't do anything out of the ordinary). Best Regards, Ruediger Ruediger Berlich wrote:
Robert, all,
I'm of course happy to help, e.g. try out fixes you propose.
The code is available at http://www.launchpad.net/geneva for you to look at, if you want. Click on "View the branch content". The code in question is in the include/geneva and src/geneva subdirectories.
I have, just for kicks, commented out the BOOST_SERIALIZATION_ASSUME_ABSTRACT in
http://bazaar.launchpad.net/~gemfony/geneva/trunk/annotate/head%3A/include/g...
plus the
BOOST_CLASS_EXPORT(Gem::Geneva::GPersonalityTraits) in
http://bazaar.launchpad.net/~gemfony/geneva/trunk/annotate/head%3A/src/genev...
My understanding is that, with gcc, Boost.Serialization is able to detect by itself that GPersonalityTraits is purely virtual, and that BOOST_CLASS_EXPORT doesn't make a difference anyway for a class that cannot be instantiated directly. However, the error message at the end of the program execution remains the same.
I am also pretty confident that serialization itself is unaffected (during the program's runtime), since server and client can communicate and the program correctly converges towards the minimum of a toy optimization problem (i.e. the right data is exchanged).
Best Regards, Ruediger
P.S.: Please do expect a few hours delay between any proposed fix and my answer, given that Robert is in the US and I am in Europe.
Robert Ramey wrote:
Anthony Williams wrote:
Eric Niebler <eric@boostpro.com> writes:
I don't know whether this is a serialization issue or a thread issue. Robert, Anthony, can you two weigh in?
Looks like a serialization problem to me.
I would agree - but its hard to reproduce from here. I don't see this as quick fix - it would require some time and help from the person who can actually reproduce it.
Robert Ramey
-- Kind Regards / Mit freundlichen Gruessen, Ruediger Berlich ------------------------------------------------------------------------ Dr. Ruediger Berlich, Dipl.-Phys./MBA | Web: http://ruediger.berlich.com Karlsruhe Institute of Technology | E-mail: ruediger.berlich@kit.edu Steinbuch Centre for Computing | Phone: +49 (0)7247 825678 Hermann-von-Helmholtz-Platz 1 | Fax: +49 (0)7247 824972 D-76344 Eggenstein-Leopoldshafen | Mobile: +49 (0)178 5567842 ------------------------------------------------------------------------ KIT – University of the State of Baden-Wuerttemberg and National Laboratory of the Helmholtz Association
participants (1)
-
Anthony Williams -
Eric Niebler -
Robert Ramey -
Ruediger Berlich