search for: msan

Hi, I have just tagged 3.7.1-rc1, so it is ready for testing. As a reminder, when doing regression testing, use the 3.7.0 release as your baseline. Thanks, Tom

...--- a/cmake/config-ix.cmake +++ b/cmake/config-ix.cmake @@ -149,7 +149,7 @@ set(ALL_ASAN_SUPPORTED_ARCH ${X86} ${X86_64} ${ARM32} ${ARM64} ${MIPS32} ${MIPS64} ${PPC64}) set(ALL_DFSAN_SUPPORTED_ARCH ${X86_64} ${MIPS64} ${ARM64}) set(ALL_LSAN_SUPPORTED_ARCH ${X86_64} ${MIPS64} ${ARM64}) -set(ALL_MSAN_SUPPORTED_ARCH ${X86_64} ${MIPS64} ${ARM64}) +set(ALL_MSAN_SUPPORTED_ARCH ${X86} ${X86_64} ${MIPS64} ${ARM64}) set(ALL_PROFILE_SUPPORTED_ARCH ${X86} ${X86_64} ${ARM32} ${ARM64} ${PPC64} ${MIPS32} ${MIPS64}) set(ALL_TSAN_SUPPORTED_ARCH ${X86_64} ${MIPS64} ${ARM64} ${PPC64}) - lib/msa...

Aside: would it be useful to execute a build of the libc++/libc++abi with msan normally during release, and change the driver to look for these msan-built C++ libs when "-fsanitize=memory"? That would drastically cut down on the complexity of using msan. On Fri, Aug 31, 2018 at 5:43 AM Dean Michael Berris via llvm-dev < llvm-dev at lists.llvm.org> wrote: &g...

Hi llvm-dev, I'm trying to reproduce an msan failure in one of the bots, but I can't seem to get the right incantation of building LLVM with msan. Here's what I've been doing: 1) Build the toolchain in one build directory, including `compiler-rt`. 2) Build the toolchain again with the just built toolchain in step 1, but this tim...

...t; while to get right. When I did I found the page: > https://github.com/google/sanitizers/wiki/MemorySanitizerBootstrappingClang > useful. The other thing that might work is following the individual > cmake steps from > http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-bootstrap-msan > . These aren't in the same structure as the monorepo but they may be > adaptable. > > My apologies if you've tried these already. > > Peter > > On 30 August 2018 at 12:42, Dean Michael Berris via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > Hi...

...016 at 7:04 PM, Brian Cain via cfe-dev < cfe-dev at lists.llvm.org> wrote: > SuSE Linux Enterprise Server 11SP3 x86_64 > > Looks like I see several failures that weren't in 3.7.1. Is there any way > to tell whether these are regressions vs new-to-3.8.0-but-failing? The > MSan ones were in 3.7.1 but the ThreadPoolTest and the libc++ errors were > not in 3.7.1. > > All of the libc++ failures seem like non-issues and should be in 3.7.1. Did you change or upgrade your platform or libc version? I'm not sure about the libc++abi error though. > ~~~~~~~~~~~~~...

...is looking good on Ubuntu 14.04 x64, uploaded: clang+llvm-3.7.0-rc2-x86_64-linux-gnu-ubuntu-14.04.tar.xz The errors reported during build are: Failing Tests (17): AddressSanitizer-x86_64-linux :: TestCases/Posix/readv.cc MemorySanitizer :: Linux/tcgetattr.cc MemorySanitizer-Unit :: Msan-x86_64-Test/MemorySanitizer.gethostent MemorySanitizer-Unit :: Msan-x86_64-Test/MemorySanitizer.gethostent_r MemorySanitizer-Unit :: Msan-x86_64-Test/MemorySanitizer.getmntent MemorySanitizer-Unit :: Msan-x86_64-Test/MemorySanitizer.getmntent_r MemorySanitizer-Unit :: Msan-x86_...

I ran "ninja check-asan" and no errors. But "ninja check-msan" had 117 errors. I took the first FAILED test, which was for eventfd.cc, and executed the command line creating an eventfd executable in a temporary directory and then executed that file using gdb. Finally, used bt to dump the stack. I've emailed llvm-admin at lists.llvm.org to setup an...

Hello testers, 4.0.0-rc3 was just tagged from the branch at r296762. This is a release candidate in the real sense: if no major issues show up with this one, it is the version that will be released. Please let me know if you find any issues, including in release notes or documentation, which will be on the pre-release web site later today. Please build, test, and upload binaries to the sftp

Dear testers, Release Candidate 3 has just been tagged [1]. Please build, test, and upload to the sftp. If there are no regressions from previous release candidates, this will be the last release candidate before the final release. Release notes can still go into the branch. Thanks again for all your work! Hans [1] http://lists.llvm.org/pipermail/llvm-branch-commits/2016-February/009866.html

Hello, I am currently porting memory sanitizer to a custom platform, and discovered some strange things in the existing implementation. 1. clang/llvm currently hardcode the list of supported platforms and disallow the use of a standalone msan implementation. I suppose the solution here is to submit a patch similar to https://reviews.llvm.org/D18865 <https://reviews.llvm.org/D18865>, which will provide the necessary arguments to configure the layout. I have it ready here. Will this approach be fine for the llvm dev team, and may I...

I recently tried to enabled building llvm libraries with -Wl,-z,defs. The intention was to detect missing dependencies on ELF, so that we don't get into a situation where a .so builds, but the equivalent .dylib or .dll fails. This failed when building with msan because of undefined references to functions like __msan_memcpy. Unfortunately, I don't think elf linkers have a way of informing them that a given symbol will be provided at runtime. It is possible to pass a dummy executable build with msan, but that gets recorded in DT_NEEDED. My understand...

...context.cc LeakSanitizer-Standalone :: TestCases/use_registers.cc MemorySanitizer :: Linux/process_vm_readv.cc MemorySanitizer :: allocator_mapping.cc MemorySanitizer :: dlerror.cc MemorySanitizer :: dtls_test.c MemorySanitizer :: memcmp_test.cc MemorySanitizer :: msan_print_shadow3.cc MemorySanitizer :: param_tls_limit.cc MemorySanitizer :: unaligned_read_origin.cc MemorySanitizer-Unit :: Msan-mips64-Test/MemorySanitizer.SmallPreAllocatedStackThread MemorySanitizer-Unit :: Msan-mips64-Test/MemorySanitizer.UnalignedLoad MemorySanitizer-Un...

...x-gnu-ubuntu-16.04.tar.xz clang+llvm-3.8.0-rc3-x86_64-linux-gnu-ubuntu-15.10.tar.xz clang+llvm-3.8.0-rc3-x86_64-linux-gnu-ubuntu-14.04.tar.xz On Ubuntu 16.04 x86_64: Failing Tests (7): MemorySanitizer :: Linux/forkpty.cc MemorySanitizer :: Linux/tcgetattr.cc MemorySanitizer-Unit :: Msan-x86_64-Test/MemorySanitizer.getmntent MemorySanitizer-Unit :: Msan-x86_64-Test/MemorySanitizer.getmntent_r MemorySanitizer-Unit :: Msan-x86_64-with-call-Test/MemorySanitizer.getmntent MemorySanitizer-Unit :: Msan-x86_64-with-call-Test/MemorySanitizer.getmntent_r Profile :: ins...

...ur custom platform has a target triple, you could submit changes to llvm, clang and compiler-rt to specify any platform-specific offsets and other details. 2. Blacklist is meant to disable checking for bugs in certain functions, not to remove all instrumentation. With ASan, these are the same. With MSan, it places instrumentation in a "safe" mode where, for example, a function that reads from A and stores to B will (1) not check A and (2) make B fully initialized even if data being stored comes from an uninitialized location. Building MSan runtime library with MSan is not going to work,...

...target triple, you > could submit changes to llvm, clang and compiler-rt to specify any > platform-specific offsets and other details. > 2. Blacklist is meant to disable checking for bugs in certain > functions, not to remove all instrumentation. With ASan, these are the > same. With MSan, it places instrumentation in a "safe" mode where, for > example, a function that reads from A and stores to B will (1) not > check A and (2) make B fully initialized even if data being stored > comes from an uninitialized location. > > Building MSan runtime library with M...

I've compiled REALEASE_390/final but all "ninja check-msan" tests are failing (http://lists.llvm.org/pipermail/llvm-dev/2016-September/104609.html) I'm waiting for an account to be created to file a bug, but in the mean time I thought I'd take a look at it myself. My system is an Arch Linux system that is up to date as of this morning: $ unam...

...h some confidence that when the application is compiled without ASan that it probably doesn't have a heap-use-after-free. > Does the application have threads? (If yes, did you run with TSan?) Not yet but I've stumbled across an issue that looks interesting. See below > Did you try msan? I just have and it immediately reported a problem. I took a closer look and it looks like a false positive to me. Here are the steps to reproduce ``` git clone https://github.com/Z3Prover/z3.git cd z3 git checkout 9ed7dadc0251db992b44984edfa6c586aab20ecb CC=clang CXX=clang++ CXXFLAGS="-fsa...

...LLVM :: tools/llvm-cov/showRegionMarkers.cpp LLVM :: tools/llvm-cov/showTemplateInstantiations.cpp LLVM :: tools/llvm-cov/universal-binary.c LLVM :: tools/llvm-cov/warnings.h These ^^ fail with "std::future_error / No associated state" as well. MemorySanitizer-Unit :: Msan-x86_64-Test/MemorySanitizer.fgetgrent_r MemorySanitizer-Unit :: Msan-x86_64-Test/MemorySanitizer.getgrent MemorySanitizer-Unit :: Msan-x86_64-Test/MemorySanitizer.getgrent_r These don't confess why they failed in the log. MemorySanitizer-Unit :: Msan-x86_64-Test/MemorySanitizer.ge...

On Wed, Jul 13, 2016 at 04:48:51PM +0200, Sedat Dilek via llvm-dev wrote: > [ CCed all people who were involved in this thread ] > > Hi Tom, > > personally, I am interested to test the prebuilt-toolchains for > Ubuntu/xenial alias 16.04 LTS and Debian/Jessie v8.5.0 AMD64. > The available toolchains are incomplete and thus useless. > > Just as a fact: There is still no