- User Since
- Mar 10 2016, 1:50 PM (253 w, 5 d)
Thu, Jan 7
Still please do not submit if D94210 does not need it.
Wed, Jan 6
Please remove and let compiler decide.
ALWAYS_INLINE may confuse future readers
Sat, Jan 2
Something is not initialized tihttp://lab.llvm.org:8011/#/builders/74/builds/1834/steps/9/logs/stdio
Wed, Dec 30
Tue, Dec 29
avoid function local static
I assume it's not needed after D93877
Mon, Dec 28
We have TEST(SanitizerLinux, ThreadDescriptorSize)
Do you know if it fails on your boxes?
Can we add #include "sanitizer_common/sanitizer_glibc_version.h" into interception_linux.h ?
check-asan complains like thins:
LGTM, I'll accept in a day or so if no other feedback
Tue, Dec 22
Dec 15 2020
Dec 14 2020
I don't have strong opinion
Dec 11 2020
Can we embed clang binary location when compiling the program?
I am not sure about this change. For the most of users it's very unlikely to have llvm-symbolizer next to the tested binary. Looks like this just simplifies few tests. I'd rather use usual approach with ASAN_OPTIONS there.
Dec 9 2020
Dec 7 2020
I've chatted about that with @kcc and @eugenis . It seems the problem the patch is trying to solve is less important than regressions. Even with the current state when rare false ODR reports are possible it still useful.
It would be nice with -fsanitize-address-use-odr-indicator, but someone will need to figure-out what to do with few users broken by binary size increase.
I was able to reproduce.
Dec 6 2020
Dec 5 2020
Dec 4 2020
Can you add a test probably in sanitizer_common which reproduces the issue?
Dec 3 2020
It intentionally calls interceptor which will call sigaction_impl where all works is done.
alias change is LGTM, we can try to figure-out how to roll out -fsanitize-address-use-odr-indicator
So with this patch no code increase but we lose ODR checks.
To preserve checks we need -fsanitize-address-use-odr-indicator but then binary size increase.
Dec 2 2020
What is going to be the default?
Dec 1 2020
I guess another cons was binary size increase? Would you like to run large scale testing on internal Google code?
remove unneded change
Nov 26 2020
74536==WARNING: MemorySanitizer: use-of-uninitialized-value
#0 0x7c7b3ed in llvm::Value::setValueName(llvm::StringMapEntry<llvm::Value*>*) /b/sanitizer-x86_64-linux-fast/build/llvm-project/llvm/lib/IR/Value.cpp:281:3 #1 0x7c78ec6 in destroyValueName /b/sanitizer-x86_64-linux-fast/build/llvm-project/llvm/lib/IR/Value.cpp:143:3 #2 0x7c78ec6 in llvm::Value::~Value() /b/sanitizer-x86_64-linux-fast/build/llvm-project/llvm/lib/IR/Value.cpp:104:3 #3 0x7b389e6 in operator() /b/sanitizer-x86_64-linux-fast/build/libcxx_build_msan/include/c++/v1/memory:2122:5 #4 0x7b389e6 in reset /b/sanitizer-x86_64-linux-fast/build/libcxx_build_msan/include/c++/v1/memory:2383:7 #5 0x7b389e6 in ~unique_ptr /b/sanitizer-x86_64-linux-fast/build/libcxx_build_msan/include/c++/v1/memory:2337:19 #6 0x7b389e6 in destroyAll /b/sanitizer-x86_64-linux-fast/build/llvm-project/llvm/include/llvm/ADT/DenseMap.h:368:25 #7 0x7b389e6 in llvm::DenseMap<llvm::Type*, std::__1::unique_ptr<llvm::PoisonValue, std::__1::default_delete<llvm::PoisonValue> >, llvm::DenseMapInfo<llvm::Type*>, llvm::detail::DenseMapPair<llvm::Type*, std::__1::unique_ptr<llvm::PoisonValue, std::__1::default_delete<llvm::PoisonValue> > > >::~DenseMap() /b/sanitizer-x86_64-linux-fast/build/llvm-project/llvm/include/llvm/ADT/DenseMap.h:754:11 #8 0x7b2f91d in llvm::LLVMContextImpl::~LLVMContextImpl() /b/sanitizer-x86_64-linux-fast/build/llvm-project/llvm/lib/IR/LLVMContextImpl.cpp:125:1 #9 0x7b19cff in llvm::LLVMContext::~LLVMContext() /b/sanitizer-x86_64-linux-fast/build/llvm-project/llvm/lib/IR/LLVMContext.cpp:94:31 #10 0x2561bb6 in main /b/sanitizer-x86_64-linux-fast/build/llvm-project/llvm/tools/llc/llc.cpp:366:1 #11 0x7f93b5e3309a in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2409a) #12 0x24e0df9 in _start (/b/sanitizer-x86_64-linux-fast/build/llvm_build_msan/bin/llc+0x24e0df9)
Nov 20 2020
Nov 19 2020
Other than file issue, compiler-rt part is LGTM
leaving the rest to @MaskRay
LGTM either way
Nov 18 2020
LGTM with some FIXME explaining that it needs investigation in future