similar to: [LLVMdev] Bootstrapping Clang with MemorySanitizer

Hi Evgeniy, Yes, it is. The problem here is that the program doesn't fail on my box (release and debug builds), so I have no idea how to debug the problem. According to the test, it's ran as "not chained_origin_with_signals.cc.tmp", expecting it to fail. Also, the FileCheck expects to find warnings on the output, for which there is none Maybe I'm missing some CMake flag or

The root cause of those issues is the fact that sanitizers verify C++-level semantics with LLVM IR level instrumentation. For example, speculative loads are OK in IR if it can be proved that the load won't trap, but in C++ it would be a data race. On Tue, Nov 19, 2013 at 8:38 PM, Kostya Serebryany <kcc at google.com> wrote: > > > > On Tue, Nov 19, 2013 at 8:25 PM, David

Yup, using SIGHUP works. On 29 July 2014 13:14, Evgeniy Stepanov <eugeni.stepanov at gmail.com> wrote: > Could it be that I'm misunderstanding signal semantics, and SIGUSR1 is > not guaranteed to be delivered (to the same process!) before kill() > returns? Could you check if that's what happens by adding a sleep() > somewhere? > > On Tue, Jul 29, 2014 at 2:17 AM,

What I'm trying to say is that according to my understanding of the C++11 memory model, even in that small reproducer, the store to g and the load from g are in fact a data race. (This is regardless of the fact the load is protected by a branch that is not taken.) From: Kostya Serebryany [mailto:kcc at google.com] Sent: Tuesday, November 19, 2013 19:46 To: Kuperstein, Michael M Cc: Evgeniy

I'm compiling compiler-rt via CMake+Ninja on x86_64+ArchLinux and one of the tests fails on ToT: MemorySanitizer :: chained_origin_with_signals.cc The text expects uninitialized warnings while the execution prints nothing, thus FileCheck fails. Anyone seeing this? cheers, --renato

On Tue, Oct 20, 2015 at 10:53 PM, Kostya Serebryany <kcc at google.com> wrote: > Can you open a separate bug with exact repro instructions? Well the bug tracker seems to require an account. But in any case I don't see anything specific to reproduce. I did an svn update of llvm and clang and built and installed (I even tried make clean and removed the old install but it didn't

On Tue, Nov 19, 2013 at 9:05 PM, Kuperstein, Michael M < michael.m.kuperstein at intel.com> wrote: > My $0.02 - I'm not sure the transformation introduces a data race. > > To the best of my understanding, the point of the C++11/C11 memory model > is to allow a wide array of compiler transformations - including > speculative loads - for non-atomic variables. > I believe

My $0.02 - I'm not sure the transformation introduces a data race. To the best of my understanding, the point of the C++11/C11 memory model is to allow a wide array of compiler transformations - including speculative loads - for non-atomic variables. I believe what's most likely happening (without looking at the Mozilla source) is that the original program contains a C++ data race, and

Just moving this branch of the thread out of the review because I don't want to derail the review thread... Kostya - why are these two cases not optimization bugs in general? (why do they only affect sanitizers?) On Mon, Nov 18, 2013 at 8:37 PM, Kostya Serebryany <kcc at google.com> wrote: > And we've been just informed by the mozilla folks about yet another case > of

On Tue, Nov 19, 2013 at 10:08 AM, Hal Finkel <hfinkel at anl.gov> wrote: > ----- Original Message ----- > > From: "Kostya Serebryany" <kcc at google.com> > > To: "Michael M Kuperstein" <michael.m.kuperstein at intel.com> > > Cc: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> > > Sent: Tuesday, November 19,

----- Original Message ----- > From: "Kostya Serebryany" <kcc at google.com> > To: "Michael M Kuperstein" <michael.m.kuperstein at intel.com> > Cc: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> > Sent: Tuesday, November 19, 2013 11:45:39 AM > Subject: Re: [LLVMdev] Curiosity about transform changes under Sanitizers (Was:

On Tue, Nov 19, 2013 at 8:25 PM, David Blaikie <dblaikie at gmail.com> wrote: > Just moving this branch of the thread out of the review because I don't > want to derail the review thread... > > Kostya - why are these two cases not optimization bugs in general? (why do > they only affect sanitizers?) > The recent case from mozilla (

----- Original Message ----- > From: "David Blaikie" <dblaikie at gmail.com> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "Kostya Serebryany" <kcc at google.com>, "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> > Sent: Tuesday, November 19, 2013 12:19:46 PM > Subject: Re: [LLVMdev] Curiosity about transform

Yes, it would be great to get that fixed. On Wed, Feb 5, 2014 at 4:09 PM, Evgeniy Stepanov <eugeni.stepanov at gmail.com>wrote: > On Thu, Feb 6, 2014 at 12:21 AM, Keno Fischer > <kfischer at college.harvard.edu> wrote: > > Looks like when you materialize the stores, you should check the size of > the > > the store and emit an appropriate amount of stores to the

On Tue, Nov 19, 2013 at 9:56 PM, Kuperstein, Michael M < michael.m.kuperstein at intel.com> wrote: > What I’m trying to say is that according to my understanding of the > C++11 memory model, even in that small reproducer, the store to g and the > load from g are in fact a data race. > > (This is regardless of the fact the load is protected by a branch that is > not

I assume there are transitions between JITted code and native helper functions. How are you handling them? Are native functions MSan-instrumented? MSan is passing shadow across function calls in TLS slots. Does your TLS implementation guarantee that accesses to __msan_param_tls from JITted and from native code map to the same memory? On Mon, Jan 27, 2014 at 11:36 PM, Evgeniy Stepanov

I have verified that both TLS implementations indeed find the same area of memory. Anything else I could look for? On Tue, Jan 28, 2014 at 4:28 PM, Keno Fischer <kfischer at college.harvard.edu>wrote: > Yes, both JIT code and the native runtime are instrumented. I am under the > impressions that the the C library should guarantee that from the way the > relocations are

How is ccall() implemented? If it manually sets up a stack frame, then it also needs to store argument shadow values in paramtls. I don't think there is an overflow, unless you have a _lot_ of arguments in a function call. On Sun, Feb 2, 2014 at 9:26 AM, Keno Fischer <kfischer at college.harvard.edu> wrote: > Also, I was looking at the instrumented LLVM code and I noticed that the

The code for ccall looks right. Sounds like you have a very small range of instructions where an uninitialized value appear. You could try debugging at asm level. Shadow for b should be passed at offset 0 in __msan_param_tls. MSan could propagate shadow through arithmetic and even some logic operations (like select). It could be that b is clean on function entry, but then something uninitialized

Hm, that bug has been closed as resolved but I still see the problem: $ clang --version clang version 3.8.0 (trunk 250848) (llvm/trunk 250846) Target: x86_64-unknown-linux-gnu Thread model: posix InstalledDir: /usr/local/bin configure:4042: ./conftest FATAL: Code 0x5615faea43f0 is out of application range. Non-PIE build? FATAL: MemorySanitizer can not mmap the shadow memory. FATAL: Make sure to