On Tue, 8 May 2018, Jonathan Wakely wrote:
On 8 May 2018 at 14:00, Jonathan Wakely wrote:
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.
N.B. I think this discussion belongs on the libstdc++ list.
Would it make sense to use the abi_tag attribute to help with that? (I
didn't really think about it, maybe it doesn't)
"don't do that" remains the most sensible answer.
--
Marc Glisse
