rokzitko / nrgljubljana

NRG Ljubljana is a numerical renormalization group implementation for solving quantum impurity problems in theoretical physics
GNU General Public License v3.0
31 stars 8 forks source link

Properly enable sanitizer runtime checks if desired, Enable them in travis #2

Closed Wentzell closed 4 years ago

Wentzell commented 4 years ago

This commit adjusts cmake to not define the sanitizer library targets asan and ubsan if they are already defined by the parent project. Also, it will enable the sanitizer runtime checks in the travis build.

The sanitizer runtime checks are currently failing due to an implementation detail in boost/serialization/singleton.hpp where a const & is binding to a nullptr in a member initialization. I see the following error for all tests

1: /cm/shared/sw/pkg/devel/boost/1.70-gcc7-openmpi2/include/boost/serialization/singleton.hpp:181:13: runtime error: reference binding to null pointer of type 'const boost::serialization::extended_type_info_typeid<boost::numeric::ublas::vector<double, boost::numeric::ublas::unbounded_array<double, std::__1::allocator<double> > > >'
1:     #0 0x16b1aed in boost::serialization::singleton<boost::serialization::extended_type_info_typeid<boost::numeric::ublas::vector<double, boost::numeric::ublas::unbounded_array<double, std::__1::allocator<double> > > > >::get_instance() /cm/shared/sw/pkg/devel/boost/1.70-gcc7-openmpi2/include/boost/serialization/singleton.hpp:181:9
1:     #1 0x4ca182 in __cxx_global_var_init.2778 /cm/shared/sw/pkg/devel/boost/1.70-gcc7-openmpi2/include/boost/serialization/singleton.hpp:207:36                                                                                                                              
1:     #2 0x1716d8c in __libc_csu_init (/cache/dropbox/Dropbox (Simons Foundation)/Coding/nrgljubljana/build/c++/nrg+0x1716d8c)
1:     #3 0x7f09c7f2b424 in __libc_start_main (/lib64/libc.so.6+0x22424)
1:     #4 0x4d9574 in _start (/cache/dropbox/Dropbox (Simons Foundation)/Coding/nrgljubljana/build/c++/nrg+0x4d9574)

This problem seems to be known for some time unfortunately, see here where they give a minimal example to reproduce the behavior.

It would be great if it would be possible to work around this in one way or the other given that the sanitizer runtime checks provide very valueable runtime information.