[llvm-dev] [msan] Failing mmap.cc test

[Evgenii Stepanov via llvm-dev]

Do you see the problem after r340957?

On Tue, Sep 11, 2018 at 6:57 AM, David Greene <dag at cray.com> wrote:

> Evgenii Stepanov <eugeni.stepanov at gmail.com> writes:
>
> > See https://reviews.llvm.org/D51364 - a very similar bug was
> > introduced by a compiler-rt change and then fixed by a revert.
>
> Ok, so what do we do about this?  D50940 seems to have introduced the
> problem but it was reverted.  The "tentative fix" in D51364 was
> abandoned but it's not clear to me why (maybe because D50940 was
> reverted?).  It is also not clear to me how D50940 could have introduced
> the problem.  Was it just coincidence that someone saw this issue after
> D50940 was applied?
>

We figured it out in https://reviews.llvm.org/D51364 - msan shadow mapping
function can not distinguish a failed mmap with a successfull mmap at
address 0 with the new interface.


>
>                              -David
>
> > On Mon, Sep 10, 2018 at 8:54 AM, David Greene via llvm-dev
> > <llvm-dev at lists.llvm.org> wrote:
> >
> >     The mmap.cc test is failing for me on aarch64 SuSE 12. The assert
> >     assert(AddrIsApp(p)) fails. The last value printed from mmap is
> >     0xf00000000 which is indeed not MAP_FAILED but also not a valid
> >     address
> >     acoording to mmap.cc's mapping table.
> >
> >     Is there something about SuSE 12's kernel that behaves differently
> >     from
> >     what this test expects? I am not a kernel guy...
> >
> >     The sequence of the last handful of addresses returned and printed
> >     by
> >     the test is:
> >
> >     0x5600000000
> >     0x5500000000
> >     0x5400000000
> >     0x5300000000
> >     0x5200000000
> >     0x5100000000
> >     0x5000000000
> >     0xf00000000
> >
> >     That jump in value looks suspicious to me.
> >
> >     Also, a lot of sanitizer symbols are reported to be "optimized
> >     out" by
> >     gdb even with a debug LLVM build and gdb gets very confused about
> >     where
> >     execution is going. Is that expected? Is there a special cmake
> >     build
> >     flag to enable more debug info in compiler-rt and/or the sanitizer
> >     runtime?
> >
> >     -David
> >     _______________________________________________
> >     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/20180911/b521c2cc/attachment.html>