[llvm-dev] greendragon build noisy due to mmap_stress.cc

[Nico Weber via llvm-dev]

Here's another one:
http://lab.llvm.org:8011/builders/clang-ppc64be-linux-multistage/builds/60

On Fri, Jan 22, 2016 at 10:53 AM, Dmitry Vyukov <dvyukov at google.com> wrote:

> On Fri, Jan 22, 2016 at 4:17 PM, Dmitry Vyukov <dvyukov at google.com> wrote:
> > On Fri, Jan 22, 2016 at 4:11 PM, Kuba Brecka <jbrecka at apple.com> wrote:
> >> Hm, I tried to reproduce this as well, but unsuccessfully.  From the
> crash
> >> report:  EXC_I386_GPFLT means we’re dereferencing a non-canonical
> pointer,
> >> in this case “0x00486000000025df”.  This happens at
> wrap_OSSpinLockLock+17,
> >> which is just after the prologue and just after calling cur_thread().
> So
> >> I’d say it happens when we’re dereferencing the pointer returned by
> >> cur_thread().  On OS X, we’re doing this trick where we store the
> >> ThreadState pointer in the shadow memory.  Could it be that something
> >> actually read/wrote the memory that is backed by the same place as the
> >> shadow memory?
> >>
> >> Does “0x00486000000025df” like a reasonable content of a shadow cell?
> >
> >
> >
> > Yes, it looks like a reasonable shadow:
> >
> > // Shadow (from most significant bit):
> > //   freed           : 1
> > //   tid             : kTidBits
> > //   is_atomic       : 1
> > //   is_read         : 1
> > //   size_log        : 2
> > //   addr0           : 3
> > //   epoch           : kClkBits
>
>
> +Nico pointed to another failure:
>
> http://lab.llvm.org:8080/green/job/clang-stage1-cmake-RA_check/9782/testReport/ThreadSanitizer/ThreadSanitizer/mmap_stress_cc/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160122/5bf72a5a/attachment.html>