On 8 May 2018 at 13:44, Stephan Bergmann wrote: > I was recently bitten by the following issue (Linux, libstdc++ 8.0.1): A > process loads two dynamic libraries A and B both using std::regex, and A is > compiled without -D_GLIBCXX_DEBUG while B is compiled with -D_GLIBCXX_DEBUG.
This is only supported in very restricted cases. > B creates an instance of std::regex, which internally creates a > std::shared_ptr<std::__detail::_NFA<std::__cxx11::regex_traits<char>>>, > where _NFA has various members of std::__debug::vector type (but which isn't > reflected in the mangled name of that _NFA instantiation itself). > > Now, when that instance of std::regex is destroyed again in library B, the > std::shared_ptr<std::__detail::_NFA<std::__cxx11::regex_traits<char>>>::~shared_ptr > destructor (and functions it in turn calls) that happens to get picked is > the (inlined, and exported due to default visibility) instance from library > A. And that assumes that that _NFA instantiation has members of non-debug > std::vector type, which causes a crash. > > Should it be considered a bug that such mixture of debug and non-debug > std::regex usage causes ODR violations? Yes, but my frank response is "don't do that". The right fix here might be to ensure that _NFA always uses the non-debug vector even in Debug Mode, but I'm fairly certain there are other similar problems lurking.
