CaseyCarter
commented
2 months ago Added a new failure from March 23 to the table. Given that these failures are all x86-specific, I now suspect the root cause is the ASan-x86-specific OPARGPLACE backend bug VSO-1974914. This issue causes thousands of checked-compiler assertion failures in internal STL ASan-x86 testing that would likely manifest as Silent Bad Codegen with a release compiler.
The fix for VSO-1974914 will likely ship in 17.11.p1. We should close this issue after updating our CI compiler to 17.11p1, and we'll reopen if we continue to see sporadic failures.
StephanTLavavej
In STL-ASan-CI runs, seemingly random x86 test cases fail with exit code 3221225477 (0xC0000005) indicating an Access Violation. Let's track sporadic AVs here and see if there's a pattern.
P0896R4_ranges_alg_remove_copyGH_001123_random_cast_out_of_rangeP0768R1_spaceship_operatorVSO_0180466_algorithm_overhaulstr1/tests/newP1023R0_constexpr_for_array_comparisonsP0448R4_spanstreamDev10_860421_deque_push_back_pop_frontrange.iota.view/iterator/ctor.default.pass.cppP1135R6_atomic_wait_vistaP2374R4_checked_arithmetic_operations+ 2 moreGH_001010_filesystem_error_encodingP2278R4_basic_const_iterator+ 1 moreNote that these invalid accesses are not caught and reported by the ASan runtime, so they are presumably uninstrumented. Together with the fact that this is ASan-only and x86-only, I suspect a race in ASan setup or teardown.