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

[David A. Greene via llvm-dev]

Scratch that, I may have lied.

I thought I had disabled this test but it appears it is active in my
local copy and not failing.  Sorry about the noise.  If I see it pop
up again I'll let you know.

                           -David

"David A. Greene via llvm-dev" <llvm-dev at lists.llvm.org> writes:

> 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>     
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev