llvm dev - Feb 2016 - greendragon build noisy due to mmap_stress.cc

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/

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>

On 01/22/2016 09:47 PM, Nico Weber via llvm-dev wrote:
> Here's another one:
> http://lab.llvm.org:8011/builders/clang-ppc64be-linux-multistage/builds/60
I just got another error. Could we possibly disable this test until this 
issue has been resolved?

Best,
Tobias

Done in r259529.

Kuba
> On 02 Feb 2016, at 17:39, Dmitry Vyukov <dvyukov at google.com>
wrote:
> 
> On Tue, Feb 2, 2016 at 5:24 PM, David Blaikie <dblaikie at gmail.com
<mailto:dblaikie at gmail.com>> wrote:
>> 
>> 
>> On Tue, Feb 2, 2016 at 8:23 AM, Nico Weber <thakis at google.com>
wrote:
>>> 
>>>
http://lab.llvm.org:8011/builders/clang-ppc64be-linux-multistage/builds/60
>>> probably didn't use OS X?
>> 
>> 
>> Fair point - Kostya/Dmitry, any ideas here?
>> 
>>> 
>>> 
>>> On Tue, Feb 2, 2016 at 11:20 AM, David Blaikie <dblaikie at
gmail.com> wrote:
>>>> 
>>>> Can we XFAIL it only on OSX/Darwin & file a bug? It sounds
like the issue
>>>> may be restricted to that platform & there's incomplete
(possibly ongoing)
>>>> investigation? That way we don't risk regressing it on the
platforms where
>>>> this does seem to be working correctly
> 
> 
> I am fine if we disable it on OSX. Tsan OSX support is very new.
> +Kuba, please add XFAIL for OSX.
> 
> 
>>>> On Tue, Feb 2, 2016 at 6:25 AM, Tobias Grosser via llvm-dev
>>>> <llvm-dev at lists.llvm.org> wrote:
>>>>> 
>>>>> On 01/22/2016 09:47 PM, Nico Weber via llvm-dev wrote:
>>>>>> 
>>>>>> Here's another one:
>>>>>> 
>>>>>>
http://lab.llvm.org:8011/builders/clang-ppc64be-linux-multistage/builds/60
>>>>> 
>>>>> 
>>>>> I just got another error. Could we possibly disable this
test until this
>>>>> issue has been resolved?
>>>>> 
>>>>> Best,
>>>>> Tobias
>>>>> 
>>>>> _______________________________________________
>>>>> LLVM Developers mailing list
>>>>> llvm-dev at lists.llvm.org
>>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160202/f2835275/attachment-0001.html>

On 02/02/2016 06:25 PM, Kuba Brecka via llvm-dev wrote:
> Done in r259529.
I unfortunately just got another failure, so this is clearly not darwin 
only or even low-noise on none-darwin platforms:

http://lab.llvm.org:8080/green/job/clang-stage1-cmake-RA_check/9965/

I very much appreciate that people are investigating this issue, but it 
would be really nice to meanwhile disable this test case.

Best,
Tobias