From c58988a9086f496177724e4c1d0277386a2ac011 Mon Sep 17 00:00:00 2001 From: Peter Wu Date: Thu, 10 May 2018 19:02:32 +0000 Subject: [PATCH] [lsan] Try to fix test failure due to compiler optimization Summary: The SanitizerCommon-lsan-x86_64-Linux test failed due to the address of the very first allocation ending up in the stack through "delete[]". Workaround this by performing another allocation. The issue was only present with optimization enabled, the test would pass with -O0. Reviewed By: vitalybuka Differential Revision: https://reviews.llvm.org/D46650 llvm-svn: 332020 --- .../Posix/sanitizer_set_death_callback_test.cc | 11 ++++------- 1 file changed, 4 insertions(+), 7 deletions(-) diff --git a/compiler-rt/test/sanitizer_common/TestCases/Posix/sanitizer_set_death_callback_test.cc b/compiler-rt/test/sanitizer_common/TestCases/Posix/sanitizer_set_death_callback_test.cc index 8d2db364114a..54272b017504 100644 --- a/compiler-rt/test/sanitizer_common/TestCases/Posix/sanitizer_set_death_callback_test.cc +++ b/compiler-rt/test/sanitizer_common/TestCases/Posix/sanitizer_set_death_callback_test.cc @@ -2,12 +2,6 @@ // REQUIRES: stable-runtime -// For standalone LSan on x86 we have a problem: compiler spills the address -// of allocated at line 42 memory thus memory block allocated in Leak() function -// ends up to be classified as reachable despite the fact we zero out 'sink' at -// the last line of main function. The problem doesn't reproduce with ASan because -// quarantine prohibits memory block reuse for different allocations. -// XFAIL: lsan-x86 // XFAIL: ubsan #include @@ -31,7 +25,10 @@ void MaybeInit(int *uninitialized) { __attribute__((noinline)) void Leak() { - sink = new char[100]; // trigger lsan report. + // Trigger lsan report. Two attempts in case the address of the first + // allocation remained on the stack. + sink = new char[100]; + sink = new char[100]; } int main(int argc, char **argv) {