<vector>, <array>: Exception: 'read access violation' in _Orphan_range_unlocked() in Debug-mode

[Spammed]

For DEBUG builds in MS Visual Studio 2019, Ver. 16.10.0, Toolset v142, I got with the code below an exception: 'read access violation' in _Orphan_range_unlocked() (possibly very similar to what is discussed here [https://stackoverflow.com/a/62605686/15157143)])

The problem does not occur if arrvec is not static.
It does not fail with a std::vector<int> directly (not in an array).
It does not fail with clang toolset nor in release nor in C++17 or in older VS versions
Because the exception only occurs in these very specific circumstances, I suspect there may be a bug in Visual Studio.
Or is it a programming error after all? I would like to understand this.

#include <vector>
#include <array>

int main()
{
    // Exception: 'read access violation' in _Orphan_range_unlocked()
    // (in C++20 MSVC Debug builds but not in C++17 nor Release)

    static std::array<std::vector<int>, 4> arrvec;
    arrvec[0].reserve(3);
    arrvec[0].emplace_back(1);  // <- Exception occurs here
}

[CaseyCarter]

I wouldn't expect it to manifest in Release builds, _Orphan_range_unlocked is part of our iterator debugging machinery that's conditional compiled away in Release builds. This is almost certainly an MSVC compiler bug triggered by the changes we made in 16.10 to support constexpr vector and string.

@miscco or @mnatsuhara, do you want to take a look at this regression?

[miscco]

I will look at it soon^TM

[Spammed]

With a large portion of hubris and hoping that this is 'only' a problem with _HAS_ITERATOR_DEBUGGING, I changed line 105 of file yvals.h to '#define _HAS_ITERATOR_DEBUGGING 0'.
With this I can debug for the moment again.
(Otherwise I would have to get the previous VS version somewhere and install it, I think).

[miscco]

Is the reserve call necessary?

[miscco]

Note that this is nearly exactly the use case why we had to bring back the iterator debugging for vector at all. It seems that again the constructor is skipped and the proxy is not properly allocated

[CaseyCarter]

With a large portion of hubris and hoping that this is 'only' a problem with _HAS_ITERATOR_DEBUGGING, I changed line 105 of file yvals.h to '#define _HAS_ITERATOR_DEBUGGING 0'.
With this I can debug for the moment again.
(Otherwise I would have to get the previous VS version somewhere and install it, I think).

The recommended/supported method for disabling iterator debugging is to define _ITERATOR_DEBUG_LEVEL to 0. This can cause some weirdness interacting with locales when linking against the DLL (/MDd) if you use non-default locales you may need to switch to linking statically (/MTd) for your debug builds.

[Spammed]

@casey: Thank you. I'm already build statically. (But, were exactly is to define _ITERATOR_DEBUG_LEVEL to 0? in yvals.h?)
@Misco: Yes the call to reserve is necessary to provoke the exception.

[miscco]

@casey I just tried it and indeed the constructor of the vector is not run properly.

Without a proxy allocated we end up crashing in _Orphan_range

I believe this is similar to a bug we had when implementing constexpr vector, where the constructor would be skipped. I thought it fixed but I think we need to get some compiler support

[miscco]

@Spammed could I get you to file a developer community ticket as this is definitly a compiler bug

[miscco]

@Spammed I do not know if you controll the code, but a simple workaround would be to explicitly value initialize the array

#include <array>
#include <vector>
using namespace std;

int main() {
    static array<vector<int>, 4> arrvec{}; // <-- all is fine on my side
    arrvec[0].reserve(3);
    arrvec[0].emplace_back(1);
}

[CaseyCarter]

@casey: Thank you. I'm already build statically. (But, were exactly is to define _ITERATOR_DEBUG_LEVEL to 0? in yvals.h?)

In your build / on the command line.

@Spammed could I get you to file a developer community ticket as this is definitely a compiler bug

I'll file it.

[CaseyCarter]

Filed DevCom-1433426. Feel free to followup there.