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

[Evgenii Stepanov via llvm-dev]

And the jump is expected because of a previous mapping that ends at
0x50...00.

On Mon, Sep 10, 2018 at 2:57 PM, Evgenii Stepanov <eugeni.stepanov at gmail.com
> wrote:

> See https://reviews.llvm.org/D51364 - a very similar bug was introduced
> by a compiler-rt change and then fixed by a revert.
>
>
> 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/20180910/85c34d6a/attachment.html>