Sporadic unresolved test failures #4308
Description
We're encountering sporadic unresolved failures. So far, they've always happened with x86 Clang in this test:
1: Unresolved Tests (1):
1: libc++ :: std/input.output/string.streams/stringbuf/stringbuf.members/view.pass.cpp:2
Test File
Occurrences
| Date | PR | Arch | Azure Pipelines Run |
|---|---|---|---|
| 2024-01-25 | #4274 | x86 | https://dev.azure.com/vclibs/STL/_build/results?buildId=15987&view=results |
| 2024-01-27 | #4345 | x86 | https://dev.azure.com/vclibs/STL/_build/results?buildId=16004&view=results |
| 2024-02-03 | #4365 | x86 | https://dev.azure.com/vclibs/STL/_build/results?buildId=16061&view=results |
Output
Thanks to #4323, we have some useful output:
UnicodeDecodeError('charmap', b'minkernel\\crts\\ucrt\\src\\appcrt\\heap\\debug_heap.cpp(904) : Assertion failed: _CrtIsValidHeapPointer(block)\r\nminkernel\\crts\\ucrt\\src\\appcrt\\heap\\debug_heap.cpp(908) : Assertion failed: is_block_type_valid(header->_block_use)\r\nHEAP CORRUPTION DETECTED: before R\xe8\xa5j\xfe\xff\x83\xc4\x08\x8dE\x08P\x8dM\xf0\xe8F6\xfe\xffPj\x05\xe8\x0e\xfc\xff\xff\x83\xc4\x08\x8dM\x08Q\x8dM\xec\xe8/6\xfe\xffPj\x04\xe8\x87\xfb\xff\xff\x83\xc4\x08\x8bM\xf4d\x89\r block (#-33686019) at 0x00EF2CD4.\nCRT detected that the application wrote to memory before start of heap buffer.\nHEAP CORRUPTION DETECTED: after R\xe8\xa5j\xfe\xff\x83\xc4\x08\x8dE\x08P\x8dM\xf0\xe8F6\xfe\xffPj\x05\xe8\x0e\xfc\xff\xff\x83\xc4\x08\x8dM\x08Q\x8dM\xec\xe8/6\xfe\xffPj\x04\xe8\x87\xfb\xff\xff\x83\xc4\x08\x8bM\xf4d\x89\r block (#-33686019) at 0x00EF2CD4.\nCRT detected that the application wrote to memory after end of heap buffer.\nminkernel\\crts\\ucrt\\src\\appcrt\\heap\\debug_heap.cpp(996) : Assertion failed: __acrt_first_block == header\r\n', 266, 267, 'character maps to <undefined>') at D:\a\_work\1\s\tests\utils\stl\test\format.py:231
Open Questions
- What's causing this
_CrtIsValidHeapPointerassertion, which is the underlying spurious failure? - Why is this specific to x86 Clang and
stringbuf.members/view.pass.cpp? Is it a library bug in ourbasic_stringbuf, a test bug, or a compiler bug? - Why is the Python machinery encountering a
UnicodeDecodeError? Is something about the test output, like the heap contents, tripping it up? Do we need to fix the Python code somewhere, or does the UCRT need to fix its output?