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

[David A. Greene via llvm-dev]

Evgenii Stepanov <eugeni.stepanov at gmail.com> writes:

> Do you see the problem after r340957?

Yes.

                           -David

> 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
>