libstdc++: ODR violation when using std::regex with and without -D_GLIBCXX_DEBUG

[Marc Glisse]

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