[compiler-rt] [compiler-rt][asan][tests] Stabilize wchar tests on Darwin/Android (PR #161624)

[Mariusz Borsa via llvm-commits]

wrotki wrote:

I can still see the failure on Darwin with this:

`llvm-project/compiler-rt/test/asan/TestCases/wcscat.cpp:22:12: error: CHECK: expected string not found in input
 // CHECK: ERROR: AddressSanitizer: stack-buffer-overflow on address [[ADDR:0x[0-9a-f]+]] at pc {{0x[0-9a-f]+}} bp {{0x[0-9a-f]+}} sp {{0x[0-9a-f]+}}
           ^
<stdin>:49:13: note: scanning from here
Good so far.
            ^

Input file: <stdin>
Check file: /Users/local/jenkins/workspace/sanitizer-next-ios-internal/llvm-project/compiler-rt/test/asan/TestCases/wcscat.cpp

-dump-input=help explains the following input dump.

Input was:
<<<<<<
          1: ================================================================= 
          2: ==8229==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x00016d45b2b4 at pc 0x000102ee97b4 bp 0x00016d45b210 sp 0x00016d45a9b0 
          3: WRITE of size 16 at 0x00016d45b2b4 thread T0 
          4:  #0 0x000102ee97b0 in wcscat+0x5b0 (libclang_rt.asan_ios_dynamic.dylib:arm64e+0x317b0) 
          5:  #1 0x0001029a81f8 in main wcscat.cpp:21 
          6:  #2 0x000196b7ed6c (<unknown module>) 
          7:  
          8: Address 0x00016d45b2b4 is located in stack of thread T0 at offset 148 in frame 
          9:  #0 0x0001029a800c in main wcscat.cpp:9 
         10:  
         11:  This frame has 2 object(s): 
         12:  [32, 80) 'goodDst' (line 12) 
         13:  [112, 148) 'badDst' (line 16) <== Memory access at offset 148 overflows this variable 
         14: HINT: this may be a false positive if your program uses some custom stack unwind mechanism, swapcontext or vfork 
         15:  (longjmp and C++ exceptions *are* supported) 
         16: SUMMARY: AddressSanitizer: stack-buffer-overflow wcscat.cpp:21 in main 
         17: Shadow bytes around the buggy address: 
         18:  0x00016d45b000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
         19:  0x00016d45b080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
         20:  0x00016d45b100: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
         21:  0x00016d45b180: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
         22:  0x00016d45b200: 00 00 00 00 f1 f1 f1 f1 00 00 00 00 00 00 f2 f2 
         23: =>0x00016d45b280: f2 f2 00 00 00 00[04]f3 f3 f3 f3 f3 00 00 00 00 
         24:  0x00016d45b300: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
         25:  0x00016d45b380: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
         26:  0x00016d45b400: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
         27:  0x00016d45b480: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
         28:  0x00016d45b500: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
         29: Shadow byte legend (one shadow byte represents 8 application bytes): 
         30:  Addressable: 00 
         31:  Partially addressable: 01 02 03 04 05 06 07  
         32:  Heap left redzone: fa 
         33:  Freed heap region: fd 
         34:  Stack left redzone: f1 
         35:  Stack mid redzone: f2 
         36:  Stack right redzone: f3 
         37:  Stack after return: f5 
         38:  Stack use after scope: f8 
         39:  Global redzone: f9 
         40:  Global init order: f6 
         41:  Poisoned by user: f7 
         42:  Container overflow: fc 
         43:  Array cookie: ac 
         44:  Intra object redzone: bb 
         45:  ASan internal: fe 
         46:  Left alloca redzone: ca 
         47:  Right alloca redzone: cb 
         48: ==8229==ABORTING 
         49: Good so far. 
check:22                 X error: no match found
>>>>>>
`

It looks like 'Good so far.' shows up _after_ the ASAN report, while the CHECK expects it before. Maybe 2>&1 merging streams for FileCheck works differently on Darwin compared to other systems?

Could you consider 'reverting to green' this and previous PR, as suggested by @thurstond?



https://github.com/llvm/llvm-project/pull/161624