Crash with Shark and Boost serialization

Description

Segmentation fault when closing an OTB runtime using Shark. Here is the backtrace:

(gdb) r
Starting program: /opt/src/build/bin/otbSupervisedTestDriver otbBoostMachineLearningModel /opt/src/Data/Input/letter_light.scale /opt/src/build/Testing/Temporary/boost_model.txt
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
2019-03-22 16:44:00 (INFO): Default RAM limit for OTB is 256 MB
2019-03-22 16:44:00 (INFO): GDAL maximum cache size is 798 MB
2019-03-22 16:44:00 (INFO): OTB will use at most 4 threads
Confusion matrix: 
644 115 
114 627 

Kappa: 0.694627583026885986328125
Overall Accuracy: 0.847333333333333382775265363307
Confusion matrix: 
644 115 
114 627 

Kappa: 0.694627583026885986328125
Overall Accuracy: 0.847333333333333382775265363307
 -> Test EXIT SUCCESS.
-------------  No control baseline tests    -------------

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff0d08462 in std::_Rb_tree_rebalance_for_erase(std::_Rb_tree_node_base*, std::_Rb_tree_node_base&) () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
(gdb) bt
#0  0x00007ffff0d08462 in std::_Rb_tree_rebalance_for_erase(std::_Rb_tree_node_base*, std::_Rb_tree_node_base&) () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#1  0x00007ffff6db8c18 in boost::serialization::typeid_system::extended_type_info_typeid_0::type_unregister() () from /usr/lib/libboost_serialization.so.1.68.0
#2  0x000000000066580e in boost::serialization::extended_type_info_typeid<boost::shared_ptr<remora::vector<double, remora::cpu_tag> > >::~extended_type_info_typeid (
    this=0x7831a8 <boost::serialization::singleton<boost::serialization::extended_type_info_typeid<boost::shared_ptr<remora::vector<double, remora::cpu_tag> > > >::get_instance()::t>) at /usr/include/boost/serialization/extended_type_info_typeid.hpp:96
#3  0x0000000000665415 in boost::serialization::singleton<boost::serialization::extended_type_info_typeid<boost::shared_ptr<remora::vector<double, remora::cpu_tag> > > >::get_instance()::singleton_wrapper::~singleton_wrapper() (
    this=0x7831a8 <boost::serialization::singleton<boost::serialization::extended_type_info_typeid<boost::shared_ptr<remora::vector<double, remora::cpu_tag> > > >::get_instance()::t>) at /usr/include/boost/serialization/singleton.hpp:121
#4  0x00007ffff0696041 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#5  0x00007ffff069613a in exit () from /lib/x86_64-linux-gnu/libc.so.6
#6  0x00007ffff0674b9e in __libc_start_main () from /lib/x86_64-linux-gnu/libc.so.6
#7  0x000000000058202a in _start ()

It is apparently a bug in libboost_serialization, due to a bad handling of singletons during dtor step (after the main returns). Sources:

This issue appears to affect Boost versions 1.65.1 to 1.68.

Steps to reproduce

  • Compile OTB with OTB_USE_SHARK=ON
  • run test leTvBoostMachineLearningModel

Configuration information

  • OS:
    • Ubuntu 18.04
    • System packages for libboost (1.65.1), gdal, ...
    • Custom build of Shark 4.0.0
  • OTB: 6.7
  • Build: clang 6.0.0 + ninja