<div dir="ltr"><div dir="ltr"><div dir="ltr">Do you see the problem after r340957?</div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Sep 11, 2018 at 6:57 AM, David Greene <span dir="ltr"><<a href="mailto:dag@cray.com" target="_blank">dag@cray.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">Evgenii Stepanov <<a href="mailto:eugeni.stepanov@gmail.com">eugeni.stepanov@gmail.com</a>> writes:<br>
<br>
> See <a href="https://reviews.llvm.org/D51364" rel="noreferrer" target="_blank">https://reviews.llvm.org/<wbr>D51364</a> - a very similar bug was<br>
> introduced by a compiler-rt change and then fixed by a revert.<br>
<br>
</span>Ok, so what do we do about this?  D50940 seems to have introduced the<br>
problem but it was reverted.  The "tentative fix" in D51364 was<br>
abandoned but it's not clear to me why (maybe because D50940 was<br>
reverted?).  It is also not clear to me how D50940 could have introduced<br>
the problem.  Was it just coincidence that someone saw this issue after<br>
D50940 was applied?<br></blockquote><div><br></div><div>We figured it out in <a href="https://reviews.llvm.org/D51364">https://reviews.llvm.org/D51364</a> - msan shadow mapping function can not distinguish a failed mmap with a successfull mmap at address 0 with the new interface.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<span class="gmail-HOEnZb"><font color="#888888"><br>
                             -David<br>
</font></span><div class="gmail-HOEnZb"><div class="gmail-h5"><br>
> On Mon, Sep 10, 2018 at 8:54 AM, David Greene via llvm-dev<br>
> <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br>
><br>
>     The mmap.cc test is failing for me on aarch64 SuSE 12. The assert<br>
>     assert(AddrIsApp(p)) fails. The last value printed from mmap is<br>
>     0xf00000000 which is indeed not MAP_FAILED but also not a valid<br>
>     address<br>
>     acoording to mmap.cc's mapping table.<br>
>     <br>
>     Is there something about SuSE 12's kernel that behaves differently<br>
>     from<br>
>     what this test expects? I am not a kernel guy...<br>
>     <br>
>     The sequence of the last handful of addresses returned and printed<br>
>     by<br>
>     the test is:<br>
>     <br>
>     0x5600000000<br>
>     0x5500000000<br>
>     0x5400000000<br>
>     0x5300000000<br>
>     0x5200000000<br>
>     0x5100000000<br>
>     0x5000000000<br>
>     0xf00000000<br>
>     <br>
>     That jump in value looks suspicious to me.<br>
>     <br>
>     Also, a lot of sanitizer symbols are reported to be "optimized<br>
>     out" by<br>
>     gdb even with a debug LLVM build and gdb gets very confused about<br>
>     where<br>
>     execution is going. Is that expected? Is there a special cmake<br>
>     build<br>
>     flag to enable more debug info in compiler-rt and/or the sanitizer<br>
>     runtime?<br>
>     <br>
>     -David<br>
>     ______________________________<wbr>_________________<br>
>     LLVM Developers mailing list<br>
>     <a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
>     <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
</div></div></blockquote></div><br></div></div></div>