search

llvm / llvm-project

The LLVM Project is a collection of modular and reusable compiler and toolchain technologies.
http://llvm.org
Other
28.52k stars 11.79k forks source link

Identify what's unstable about ARM for sanitizers #30422

Open rengolin opened 7 years ago

rengolin commented 7 years ago
Bugzilla Link 31074
Version unspecified
OS Linux
CC @zatrazz,@asl,@rovka,@kcc,@smithp35,@vitalybuka

Extended Description

A while ago, when we started testing the sanitizers on ARM, we have identified a number of "unstable" tests that could not be easily explained.

The test fail consistently on a board+OS combination, however, on different boards and similar OS (+compiler+libs+tools), the test pass. Also, some configurations pass on stage 1 and fail on stage 2 and 3, but on others, the same test fails on stage 1 and pass on stage 2 and 3.

Pass here generally means the stack trace is in the correct order and have captured the function names correctly, while fail means the location was "unknown", or the stack track failed completely, due to unwind failures.

Here's the list of all 36 the tests that were disabled with the "stable-runtime" flag:

asan/TestCases/Posix/current_allocated_bytes.cc asan/TestCases/Posix/stack-overflow.cc asan/TestCases/Posix/deep_thread_stack.cc asan/TestCases/Posix/asan-symbolize-sanity-test.cc asan/TestCases/Posix/gc-test.cc asan/TestCases/alloca_loop_unpoisoning.cc asan/TestCases/double-free.cc asan/TestCases/debug_stacks.cc asan/TestCases/alloca_vla_interact.cc asan/TestCases/use-after-free-right.cc asan/TestCases/use-after-delete.cc asan/TestCases/invalid-free.cc asan/TestCases/sanity_check_pure_c.c asan/TestCases/vla_condition_overflow.cc asan/TestCases/vla_loop_overfow.cc asan/TestCases/use-after-free.cc asan/TestCases/deep_stack_uaf.cc asan/TestCases/large_func_test.cc asan/TestCases/strncpy-overflow.cc asan/TestCases/Linux/malloc_delete_mismatch.cc asan/TestCases/Linux/uar_signals.cc asan/TestCases/Linux/stack-trace-dlclose.cc ubsan/TestCases/Misc/nonnull-arg.cpp ubsan/TestCases/TypeCheck/vptr-corrupted-vtable-itanium.cpp ubsan/TestCases/TypeCheck/vptr.cpp safestack/canary.c safestack/overflow.c sanitizer_common/TestCases/Posix/getpass.cc sanitizer_common/TestCases/Posix/dedup_token_length_test.cc sanitizer_common/TestCases/Posix/sanitizer_set_death_callback_test.cc sanitizer_common/TestCases/Posix/sanitizer_set_report_fd_test.cc sanitizer_common/TestCases/Linux/decorate_proc_maps.cc tsan/ignore_lib1.cc tsan/ignore_lib0.cc tsan/ignore_lib3.cc msan/Linux/mallinfo.cc

rengolin commented 6 years ago

This bug was create to serve the purpose of cataloguing the errors, more than to expect anyone to fix them. In that view, I think it did pretty well.

I'm happy for this bug to be closed "won't fix" because no one has the time to look at this issue and no one needs it bad enough as to stop other tasks and take on this one.

I'm also happy for Vitaly (or someone else) to take ownership and have a go. It should really be as simple as running the tests on Arm.

Just a note, some of the original "unstable-runtime" was also due to the difference of glibc on x86 vs. Arm Linux, because sanitizers hook up breakpoints on specific libc functions, so they may have to add the functionality to the sanitizers to work well.

smithp35 commented 6 years ago

We've checked through the outstanding sanitizer UNSUPPORTED and XFAIL tests on ARM and AArch64.

The full list of UNSUPPORTED and XFAIL is: XFAILS ARM asan/TestCases/Posix/new_array_cookie_with_new_from_class.cc

XFAILS AArch64 asan/TestCases/Linux/static_tls.cc msan/param_tls_limit.cc tsan/map32bit.cc

UNSUPPORTED ARM asan/TestCases/Posix/stack-use-after-return.cc asan/TestCases/Posix/strndup_oob_test2.cc asan/TestCases/Posix/strndup_oob_test.cc asan/TestCases/heavy_uar_test.cc lsan/TestCases/large_allocation_leak.cc lsan/TestCases/Linux/use_tls_dynamic.cc lsan/TestCases/swapcontext.cc lsan/TestCases/many_tls_keys.cc

UNSUPPORTED AArch64

asan/TestCases/Posix/stack-use-after-return.cc asan/TestCases/Linux/allocator_oom_test.cc msan/allocator_mapping.cc msan/Linux/mallinfo.cc tsan/ignore_lib4.cc

Looking at the source code commits and git annotate I think the following tests don't have a specific enough reason for failing. The others point out a specific problem that needs to be fixed, or a missing feature, hence satisfying the identify what's unstable question.

XFAIL AArch64 msan/param_tls_limit.cc // void f801(S<801>): Assertion `__msan_test_shadow(&s, sizeof(s)) == -1' // failed

UNSUPPORTED ARM asan/TestCases/Posix/stack-use-after-return.cc // FIXME: Fix this test for dynamic runtime on arm linux.

asan/TestCases/heavy_uar_test.cc // FIXME: Fix this test for dynamic runtime on arm linux.

lsan/TestCases/swapcontext.cc lsan/TestCases/many_tls_keys.cc lsan/TestCases/Linux/use_tls_dynamic.cc // This patch enables LSan for arm Linux. // Disabled from first Arm support checkin https://reviews.llvm.org/D29586 // Review mentions something about Arm specific unwinding, but not conclusive.

UNSUPPORTED AArch64

tsan/ignore_lib4.cc // aarch64 bots failed with "called_from_lib suppression // 'libignore_lib4.so' is matched against 2 libraries"

allocator_oom_test.cc // AArch64 bots fail on this test.

asan/TestCases/Posix/stack-use-after-return.cc // This test runs out of stack on AArch64.

I'm on the fence with: UNSUPPORTED msan/Linux/mallinfo.cc // Factor out "stable-runtime" feature and enable it on all android. // This is a very poorly named feature. I think originally it meant to cover // linux only, but the use of it in msan // seems to be about any aarch64 platform. Anyway, this change should be NFC on // everything except Android.

My personal opinion is that we resolve this when the remaining insufficiently explained failures have a precise enough cause. I don't think that there is anyone actively working on this though.

vitalybuka commented 6 years ago

Any updates?

rengolin commented 7 years ago

Two new ones:

'SanitizerCommon-asan-armhf-Linux :: sanitizer_coverage_trace_pc_guard-dso.cc' 'SanitizerCommon-asan-armhf-Linux :: sanitizer_coverage_trace_pc_guard.cc'

http://lab.llvm.org:8011/builders/clang-cmake-armv7-a15-full/builds/1489

rengolin commented 7 years ago

TestCases/Posix/halt_on_error-torture.cc failed on Phase3 of 3.9.1 release. It could be related.

Also, we have some XPASSes for a while on Phase3:

Unexpected Passing Tests (12): AddressSanitizer-armhf-linux :: TestCases/Linux/malloc_delete_mismatch.cc AddressSanitizer-armhf-linux :: TestCases/Linux/stack-trace-dlclose.cc AddressSanitizer-armhf-linux :: TestCases/Posix/asan-symbolize-sanity-test.cc AddressSanitizer-armhf-linux :: TestCases/deep_stack_uaf.cc AddressSanitizer-armhf-linux :: TestCases/double-free.cc AddressSanitizer-armhf-linux :: TestCases/invalid-free.cc AddressSanitizer-armhf-linux :: TestCases/large_func_test.cc AddressSanitizer-armhf-linux :: TestCases/sanity_check_pure_c.c AddressSanitizer-armhf-linux :: TestCases/strncpy-overflow.cc AddressSanitizer-armhf-linux :: TestCases/use-after-delete.cc AddressSanitizer-armhf-linux :: TestCases/use-after-free-right.cc AddressSanitizer-armhf-linux :: TestCases/use-after-free.cc

could be all related to the same causes.

rengolin commented 7 years ago

Adding another one:

sanitizer_common/TestCases/Linux/soft_rss_limit_mb_test.cc

it was randomly failing on AArch64:

http://lab.llvm.org:8011/builders/clang-cmake-aarch64-full/builds/493

rengolin commented 7 years ago

One issue that springs to mind is the difference between the Clang and GCC defaults for ARM and Thumb, which are different.

So, if Arch is "armv7l", Clang defaults to ARMv7A+Cortex-A8+ARM+NEON, while GCC defaults to ARMv7M+Generic+Thumb2+VFPv3, which could explain some of the differences between Clang and GCC.

Still, this could be considered "unstable" environment from a user point of view. If that's the only problem, then "fixing" it means implementing the sanitizers on ARM and Thumb2, NEON and VFP, hard-float and soft-float, etc.