en Copyright 2015 Java http://172.16.0.5:8080/history/llvm-project-15.0.7/compiler-rt/test/asan/TestCases/lsan_crash.cpp#09170626 [lsan][lsan] Use --std=c++14 to fix Windows test List of files: /llvm-project-15.0.7/compiler-rt/test/asan/TestCases/lsan_crash.cpp Tue, 23 Mar 2021 04:38:15 +0000 Vitaly Buka <vitalybuka@google.com> http://172.16.0.5:8080/history/llvm-project-15.0.7/compiler-rt/test/asan/TestCases/lsan_crash.cpp#6ca178cd [asan] specify c++ version in tests to fix compile errorIf we don't specify the c++ version in these tests, it could cause compile errors because the compiler could default to an older c++rdar://75247244Reviewed By: vitalybukaDifferential Revision: https://reviews.llvm.org/D98913 List of files: /llvm-project-15.0.7/compiler-rt/test/asan/TestCases/lsan_crash.cpp Fri, 19 Mar 2021 02:14:40 +0000 Emily Shi <code@emi.sh> http://172.16.0.5:8080/history/llvm-project-15.0.7/compiler-rt/test/asan/TestCases/lsan_crash.cpp#c05095cd [Asan] Don't crash if metadata is not initializedFixes https://github.com/google/sanitizers/issues/1193.AsanChunk can be uninitialized yet just after return from the secondaryallocator. If lsan starts scan just before metadata assignment it canfail to find corresponding AsanChunk.It should be safe to ignore this and let lsan to assume thatAsanChunk is in the beginning of the block. This block is from thesecondary allocator and created with mmap, so it should not containany pointers and will make lsan to miss some leaks.Similar already happens for primary allocator. If it can't find realAsanChunk it falls back and assume that block starts with AsanChunk.Then if the block is already returned to allocator we have garbage inAsanChunk and may scan dead memory hiding some leaks.I'll fix this in D87135.Reviewed By: morehouseDifferential Revision: https://reviews.llvm.org/D86931 List of files: /llvm-project-15.0.7/compiler-rt/test/asan/TestCases/lsan_crash.cpp Tue, 01 Sep 2020 11:49:49 +0000 Vitaly Buka <vitalybuka@google.com>