`<forward_list>`, `<string>`, `<vector>`: Debug mode STL causes `terminate()` to be called under low memory

[AlexGuteniev]

Describe the bug
std::basic_string, std::vector default constructor is noexcept, which corresponds to the standard, but it allocates during construction, and thus may throw

Command-line test case
9525-ms-bug-repros.zip

STL version

Microsoft Visual Studio Professional 2019 Preview
Version 16.7.0 Preview 3.1

Additional context
Also tracked by DevCom-77779 and VSO-466800 / AB#466800

Similar issue is also tracked by Also tracked by DevCom-246249 and VSO-470756 / AB#470756

[StephanTLavavej]

Yep - I have a fix stranded in our vNext branch in TFS (that avoids allocating the "proxy" object; I implemented the fix for all containers except deque and vector<bool> before running out of time, but it can be finished).

[frederick-vs-ja]

Currently constexpr std::vector<T> v{}; compiles in release mode (_ITERATOR_DEBUG_LEVEL == 0) but not in debug mode, which is surprisingly inconsitent. Such inconsistency can't be fixed as long as the proxy object is dynamically allocated.

In vNext, it seems that the proxy becomes a subobject of the container object. However, if the proxy is still self-referential, there will still be inconsistency:

• in release mode, constexpr std::vector<T> v{}; compiles wherever the variable is, however,
• in debug mode, it only compiles if v has static storage duration!

This inconsistency is already present for libstdc++'s basic_string (can't be fixed without ABI break, too). Will vNext get rid of the self-reference problem?

[StephanTLavavej]

The iterator debugging overhaul that I wrote for vNext (in our stranded Team Foundation Version Control branch) entirely eliminated the proxy object, instead taking a lock whenever it needs to update all children. (I didn't get around to overhauling deque and vector<bool> but it should be possible to update them too).