I attempted to build OpenMC by supplying the compiler flag -D_GLIBCXX_DEBUG to cmake as follows.
cmake -Ddebug=on -Ddagmc=on -DCMAKE_INSTALL_PREFIX=<install_path> -DCMAKE_CXX_FLAGS="-O0 -g -D_GLIBCXX_DEBUG" ../
Both MOAB and DagMC were built with the same flag.
It built fine, but when I attempted a run I got some mysterious exception raised from within xtensor::sum, for which the backtrace is:
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1 0x00007ffff6515859 in __GI_abort () at abort.c:79
#2 0x00007ffff67a0149 in ?? () from /lib/x86_64-linux-gnu/libstdc++.so.6
#3 0x00007ffff77ffb66 in std::is_sorted_until<unsigned long const*, std::less_equal<void> > (__first=0x7fffffffd620, __last=0x7fffffffd628, __comp=...)
at /usr/include/c++/9/bits/stl_algo.h:3279
#4 0x00007ffff77fc9d9 in std::is_sorted<unsigned long const*, std::less_equal<void> > (__first=0x7fffffffd620, __last=0x7fffffffd628, __comp=...)
at /usr/include/c++/9/bits/stl_algo.h:3219
#5 0x00007ffff77fa336 in xt::xreducer<xt::xreducer_functors<std::plus<double>, xt::const_value<double>, std::plus<double> >, xt::xtensor_container<xt::uvector<double, std::allocator<double> >, 1ul, (xt::layout_type)1, xt::xtensor_expression_tag> const&, std::__debug::array<unsigned long, 1ul>, xt::reducer_options<double, std::tuple<xt::evaluation_strategy::lazy_type> > >::xreducer<xt::xreducer_functors<std::plus<double>, xt::const_value<double>, std::plus<double> >, xt::xtensor_container<xt::uvector<double, std::allocator<double> >, 1ul, (xt::layout_type)1, xt::xtensor_expression_tag>&, std::__debug::array<unsigned long, 1ul>, std::tuple<xt::evaluation_strategy::lazy_type>&> (this=0x7fffffffd5f0, func=..., e=..., axes=..., options=std::tuple containing = {...})
at /home/helen/Projects/openmc/fork/openmc/vendor/xtensor/include/xtensor/xreducer.hpp:1207
#6 0x00007ffff77f8c71 in xt::detail::reduce_impl<xt::xreducer_functors<std::plus<double>, xt::const_value<double>, std::plus<double> >, xt::xtensor_container<xt::uvector<double, std::allocator<double> >, 1ul, (xt::layout_type)1, xt::xtensor_expression_tag>&, std::__debug::array<unsigned long, 1ul>, std::tuple<xt::evaluation_strategy::lazy_type>&> (f=..., e=..., axes=..., options=std::tuple containing = {...})
at /home/helen/Projects/openmc/fork/openmc/vendor/xtensor/include/xtensor/xreducer.hpp:791
#7 0x00007ffff77f8d4a in xt::reduce<xt::xreducer_functors<std::plus<double>, xt::const_value<double>, std::plus<double> >, xt::xtensor_container<xt::uvector<double, std::allocator<double> >, 1ul, (xt::layout_type)1, xt::xtensor_expression_tag>&, std::tuple<xt::evaluation_strategy::lazy_type>&, 0> (f=..., e=...,
options=std::tuple containing = {...}) at /home/helen/Projects/openmc/fork/openmc/vendor/xtensor/include/xtensor/xreducer.hpp:875
#8 0x00007ffff77f8deb in xt::sum<void, xt::xtensor_container<xt::uvector<double, std::allocator<double> >, 1ul, (xt::layout_type)1, xt::xtensor_expression_tag>&, std::tuple<xt::evaluation_strategy::lazy_type>, 0> (e=..., es=std::tuple containing = {...})
at /home/helen/Projects/openmc/fork/openmc/vendor/xtensor/include/xtensor/xmath.hpp:1871
#9 0x00007ffff78a7ccd in openmc::Material::normalize_density (this=0x5555557b3460) at /home/helen/Projects/openmc/fork/openmc/src/material.cpp:386
#10 0x00007ffff78a7ad2 in openmc::Material::finalize (this=0x5555557b3460) at /home/helen/Projects/openmc/fork/openmc/src/material.cpp:363
#11 0x00007ffff7810493 in openmc::read_ce_cross_sections (nuc_temps=std::__debug::vector of length 9, capacity 9 = {...},
thermal_temps=std::__debug::vector of length 0, capacity 0) at /home/helen/Projects/openmc/fork/openmc/src/cross_sections.cpp:250
#12 0x00007ffff785f488 in openmc::read_input_xml () at /home/helen/Projects/openmc/fork/openmc/src/initialize.cpp:268
#13 0x00007ffff785e35a in openmc_init (argc=1, argv=0x7fffffffdcb8, intracomm=0x7fffffffdbb0)
at /home/helen/Projects/openmc/fork/openmc/src/initialize.cpp:74
#14 0x000055555556286b in main (argc=1, argv=0x7fffffffdcb8) at /home/helen/Projects/openmc/fork/openmc/src/main.cpp:19
I didn’t run the full test suite as that takes quite a long time with debug symbols, but e.g. pytest -k test_lib --capture=no aborts with a similar looking error
unit_tests/test_lib.py /usr/include/c++/9/bits/stl_algo.h:3279:
In function:
_FIter std::is_sorted_until(_FIter, _FIter, _Compare) [with _FIter =
const long unsigned int*; _Compare = std::less_equal]
Error: comparison doesn't meet irreflexive requirements, assert(!(a < a)).
Objects involved in the operation:
instance "functor" @ 0x0x7ffe97028def {
type = std::less_equal<void>;
}
iterator::value_type "ordered type" {
type = unsigned long;
}
Fatal Python error: Aborted
Current thread 0x00007fb5e42c7740 (most recent call first):
File "/home/helen/Projects/openmc/fork/openmc/openmc/lib/core.py", line 214 in init
File "/home/helen/Projects/openmc/fork/openmc/tests/unit_tests/test_lib.py", line 85 in lib_init
It may well be that this is an xtensor rather than an OpenMC problem. But I’m wondering has anyone else tried building with -D_GLIBCXX_DEBUG? Any advice would be helpful, even if the conclusion is that attempting this is a bad idea.
(For context, the reason I am attempting this is a project I’m working on for which OpenMC is a dependency enables this flag when building in debug mode, but it seems that this results incompatible library symbols if the dependencies are not also built with this flag).