[llvm-dev] [compiler-rt][msan] msan tests failing on AArch64

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

[llvm-dev] [compiler-rt][msan] msan tests failing on AArch64

Amara Emerson via llvm-dev
Hi,

I'm getting the following running msan tests on one of our AArch64
boxes:

FATAL: Code 0xaaacc3f5d4b0 is out of application range. Non-PIE build?
FATAL: MemorySanitizer can not mmap the shadow memory.
FATAL: Make sure to compile with -fPIE and to link with -pie.
FATAL: Disabling ASLR is known to cause this error.
FATAL: If running under GDB, try 'set disable-randomization off'.

ASLR is enabled.  The tests work on another AArch64 box so I don't think
it's a problem with the test, per se.  msan.h indeed shows this address
to be invalid:

#elif SANITIZER_LINUX && defined(__aarch64__)

// The mapping describes both 39-bits, 42-bits, and 48-bits VMA.  AArch64
// maps:
// - 0x0000000000000-0x0000010000000: 39/42/48-bits program own segments
// - 0x0005500000000-0x0005600000000: 39-bits PIE program segments
// - 0x0007f80000000-0x0007fffffffff: 39-bits libraries segments
// - 0x002aa00000000-0x002ab00000000: 42-bits PIE program segments
// - 0x003ff00000000-0x003ffffffffff: 42-bits libraries segments
// - 0x0aaaaa0000000-0x0aaab00000000: 48-bits PIE program segments
// - 0xffff000000000-0x1000000000000: 48-bits libraries segments
// It is fragmented in multiples segments to increase the memory available
// on 42-bits (12.21% of total VMA available for 42-bits and 13.28 for
// 39 bits). The 48-bits segments only cover the usual PIE/default segments
// plus some more segments (262144GB total, 0.39% total VMA).
const MappingDesc kMemoryLayout[] = {
    {0x00000000000ULL, 0x01000000000ULL, MappingDesc::INVALID, "invalid"},
[...]
    {0x0AAAAA0000000ULL, 0x0AAAB00000000ULL, MappingDesc::APP, "app-14"},
    {0x0AAAB00000000ULL, 0x0AACAA0000000ULL, MappingDesc::INVALID, "invalid"},
    {0x0AACAA0000000ULL, 0x0AACB00000000ULL, MappingDesc::SHADOW, "shadow-14"},
    {0x0AACB00000000ULL, 0x0AADAA0000000ULL, MappingDesc::INVALID, "invalid"},
    {0x0AADAA0000000ULL, 0x0AADB00000000ULL, MappingDesc::ORIGIN, "origin-14"},
    {0x0AADB00000000ULL, 0x0FF9F00000000ULL, MappingDesc::INVALID, "invalid"},
    {0x0FF9F00000000ULL, 0x0FFA000000000ULL, MappingDesc::SHADOW, "shadow-15"},
    {0x0FFA000000000ULL, 0x0FFAF00000000ULL, MappingDesc::INVALID, "invalid"},
    {0x0FFAF00000000ULL, 0x0FFB000000000ULL, MappingDesc::ORIGIN, "origin-15"},
    {0x0FFB000000000ULL, 0x0FFFF00000000ULL, MappingDesc::INVALID, "invalid"},
    {0x0FFFF00000000ULL, 0x1000000000000ULL, MappingDesc::APP, "app-15"},
};

It looks like the address is in the invalid area between app-14 and
shadow-14.  I remember I had a similar problem a few months ago and was
pointed to a commit that fixed it.  When we updated to that commit, it
fixed those tests.  But we're pretty up-to-date now and I am seeing
these kinds of failures.

From what I can glean, I assume that an application that finds itself in
an invalid area has a memory footprint that has grown beyond what msan
expects.  Is that basically right?  If so, I don't understand why this
would work on one AArch64 box and not another.  AFAIK the processors are
the same.  The working one is SuSE 12.2 and the non-working one is SuSE
12.3.  I wonder if something about kernel differences between the two is
causing this.  Memory ulimits are unlimited.  Anyone have ideas or
things to try?

Thanks!

                            -David
_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] [compiler-rt][msan] msan tests failing on AArch64

Amara Emerson via llvm-dev


On 24/10/2018 18:30, David Greene via llvm-dev wrote:

> Hi,
>
> I'm getting the following running msan tests on one of our AArch64
> boxes:
>
> FATAL: Code 0xaaacc3f5d4b0 is out of application range. Non-PIE build?
> FATAL: MemorySanitizer can not mmap the shadow memory.
> FATAL: Make sure to compile with -fPIE and to link with -pie.
> FATAL: Disabling ASLR is known to cause this error.
> FATAL: If running under GDB, try 'set disable-randomization off'.
>
> ASLR is enabled.  The tests work on another AArch64 box so I don't think
> it's a problem with the test, per se.  msan.h indeed shows this address
> to be invalid:
>
> #elif SANITIZER_LINUX && defined(__aarch64__)
>
> // The mapping describes both 39-bits, 42-bits, and 48-bits VMA.  AArch64
> // maps:
> // - 0x0000000000000-0x0000010000000: 39/42/48-bits program own segments
> // - 0x0005500000000-0x0005600000000: 39-bits PIE program segments
> // - 0x0007f80000000-0x0007fffffffff: 39-bits libraries segments
> // - 0x002aa00000000-0x002ab00000000: 42-bits PIE program segments
> // - 0x003ff00000000-0x003ffffffffff: 42-bits libraries segments
> // - 0x0aaaaa0000000-0x0aaab00000000: 48-bits PIE program segments
> // - 0xffff000000000-0x1000000000000: 48-bits libraries segments
> // It is fragmented in multiples segments to increase the memory available
> // on 42-bits (12.21% of total VMA available for 42-bits and 13.28 for
> // 39 bits). The 48-bits segments only cover the usual PIE/default segments
> // plus some more segments (262144GB total, 0.39% total VMA).
> const MappingDesc kMemoryLayout[] = {
>     {0x00000000000ULL, 0x01000000000ULL, MappingDesc::INVALID, "invalid"},
> [...]
>     {0x0AAAAA0000000ULL, 0x0AAAB00000000ULL, MappingDesc::APP, "app-14"},
>     {0x0AAAB00000000ULL, 0x0AACAA0000000ULL, MappingDesc::INVALID, "invalid"},
>     {0x0AACAA0000000ULL, 0x0AACB00000000ULL, MappingDesc::SHADOW, "shadow-14"},
>     {0x0AACB00000000ULL, 0x0AADAA0000000ULL, MappingDesc::INVALID, "invalid"},
>     {0x0AADAA0000000ULL, 0x0AADB00000000ULL, MappingDesc::ORIGIN, "origin-14"},
>     {0x0AADB00000000ULL, 0x0FF9F00000000ULL, MappingDesc::INVALID, "invalid"},
>     {0x0FF9F00000000ULL, 0x0FFA000000000ULL, MappingDesc::SHADOW, "shadow-15"},
>     {0x0FFA000000000ULL, 0x0FFAF00000000ULL, MappingDesc::INVALID, "invalid"},
>     {0x0FFAF00000000ULL, 0x0FFB000000000ULL, MappingDesc::ORIGIN, "origin-15"},
>     {0x0FFB000000000ULL, 0x0FFFF00000000ULL, MappingDesc::INVALID, "invalid"},
>     {0x0FFFF00000000ULL, 0x1000000000000ULL, MappingDesc::APP, "app-15"},
> };
>
> It looks like the address is in the invalid area between app-14 and
> shadow-14.  I remember I had a similar problem a few months ago and was
> pointed to a commit that fixed it.  When we updated to that commit, it
> fixed those tests.  But we're pretty up-to-date now and I am seeing
> these kinds of failures.
>
> From what I can glean, I assume that an application that finds itself in
> an invalid area has a memory footprint that has grown beyond what msan
> expects.  Is that basically right?  If so, I don't understand why this
> would work on one AArch64 box and not another.  AFAIK the processors are
> the same.  The working one is SuSE 12.2 and the non-working one is SuSE
> 12.3.  I wonder if something about kernel differences between the two is
> causing this.  Memory ulimits are unlimited.  Anyone have ideas or
> things to try?

This seems to be printed by InitShadow and it is an initialization routine
which runs on all msan enabled binaries.  The only issue I think is runtime
is set __msan_track_origins by -msan-track-origins=1 option and unfortunately
it does not seem to be stressed in any testcase. Is it the case on this binary
you are testing?
_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] [compiler-rt][msan] msan tests failing on AArch64

Amara Emerson via llvm-dev
Adhemerval Zanella via llvm-dev <[hidden email]> writes:

> This seems to be printed by InitShadow and it is an initialization routine
> which runs on all msan enabled binaries.  The only issue I think is runtime
> is set __msan_track_origins by -msan-track-origins=1 option and unfortunately
> it does not seem to be stressed in any testcase. Is it the case on this binary
> you are testing?

These are existing tests in the repository.  I don't see
-msan-track-origins set in the RUN lines so that can't be the only thing
that enables this message.

                          -David
_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] [compiler-rt][msan] msan tests failing on AArch64

Amara Emerson via llvm-dev
Could you run the binary a few times and collect different code addresses it complains about?
Could be a change in ASLR randomness.
It looks like the ranges in aarch64 shadow mapping are unnecessarily restrictive.
I did not test this, but the following seems possible:
app-14 0x0AAA000000000 .. 0x0AAB000000000
shadow-14 0x0AAC000000000 .. 0x0AAD000000000
origin-14 0x0AAD000000000 .. 0x0AAE000000000


On Thu, Oct 25, 2018 at 6:42 AM David Greene via llvm-dev <[hidden email]> wrote:
Adhemerval Zanella via llvm-dev <[hidden email]> writes:

> This seems to be printed by InitShadow and it is an initialization routine
> which runs on all msan enabled binaries.  The only issue I think is runtime
> is set __msan_track_origins by -msan-track-origins=1 option and unfortunately
> it does not seem to be stressed in any testcase. Is it the case on this binary
> you are testing?

These are existing tests in the repository.  I don't see
-msan-track-origins set in the RUN lines so that can't be the only thing
that enables this message.

                          -David
_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] [compiler-rt][msan] msan tests failing on AArch64

Amara Emerson via llvm-dev
Below are some of the failing addresses for two different tests.  I've
got about 20 or so tests that fail in this way.  Thanks for looking into
this!

Is there a description somewhere of how these maps are determined?

> I did not test this, but the following seems possible:
> app-14 0x0AAA000000000 .. 0x0AAB000000000
> shadow-14 0x0AAC000000000 .. 0x0AAD000000000
> origin-14 0x0AAD000000000 .. 0x0AAE000000000

That would seem to agree with the data below, though I never saw 0xaaaf
as a prefix in 10,000 runs.  The highest I ever saw was 0xaaaea.

                          -David


Test 1
0xaaad8cf2d490
0xaaabc698d490
0xaaab7aafd490
0xaaae3aa4d490
0xaaab6ec2d490
0xaaad64a1d490
0xaaac01f7d490
0xaaab057cd490
0xaaae0bb8d490
0xaaadb2fbd490
0xaaae8547d490
0xaaacc277d490
0xaaab704ed490
0xaaada62bd490
0xaaac4737d490
0xaaac76a7d490
0xaaadd1a4d490
0xaaaccbc2d490
0xaaae080dd490
0xaaadc414d490
0xaaad5dedd490
0xaaabb7f5d490
0xaaae4165d490
0xaaab9814d490
0xaaab94dad490
0xaaae124ed490
0xaaac6f82d490
0xaaab7c54d490
0xaaae3e32d490
0xaaae7a48d490
0xaaabf769d490
0xaaae6de9d490
0xaaad7eaed490
0xaaabe97ed490
0xaaabe58fd490
0xaaad363fd490
0xaaae3717d490
0xaaac13e8d490
0xaaad3c45d490
0xaaab4d37d490
0xaaaea00ed490
0xaaadcb95d490
0xaaae1888d490
0xaaab5530d490
0xaaac6a9ed490
0xaaacbe7fd490
0xaaabcc8cd490
0xaaac2701d490
0xaaad01afd490
0xaaad0dadd490
0xaaad7dead490
0xaaab7eb0d490
0xaaac8ed5d490
0xaaae8013d490
0xaaae3be8d490
0xaaacec0bd490
0xaaab6f3cd490
0xaaacbfa1d490
0xaaad8fead490
0xaaabc10bd490
0xaaad9a5ad490
0xaaabecc5d490
0xaaac0802d490
0xaaab00bcd490
0xaaae8b0ed490
0xaaacdc4dd490
0xaaae2cedd490
0xaaadcec2d490
0xaaae0ac6d490
0xaaace326d490
0xaaae39a8d490
0xaaadb117d490
0xaaac32fad490
0xaaabb1c9d490
0xaaaccd47d490
0xaaad17f0d490
0xaaad252fd490
0xaaad7183d490
0xaaab1010d490
0xaaac75ffd490
0xaaae45cbd490
0xaaab9b7cd490
0xaaae41fad490
0xaaadb898d490
0xaaab0589d490
0xaaab9990d490
0xaaac4babd490
0xaaab19a4d490
0xaaae0d16d490
0xaaab6f92d490
0xaaadb5d1d490

Test 2
0xaaae5938d4b0
0xaaab5134d4b0
0xaaad3461d4b0
0xaaabbe42d4b0
0xaaae3d0dd4b0
0xaaade03ad4b0
0xaaac7f14d4b0
0xaaabd7f0d4b0
0xaaae553ed4b0
0xaaac04d7d4b0
0xaaad5b02d4b0
0xaaaea137d4b0
0xaaabdb2cd4b0
0xaaabf431d4b0
0xaaac933ad4b0
0xaaab5564d4b0
0xaaae84c5d4b0
0xaaac2af5d4b0
0xaaacf5ecd4b0
0xaaad7d2bd4b0
0xaaaba9e6d4b0
0xaaae97cfd4b0
0xaaab21d5d4b0
0xaaad6c3bd4b0
0xaaac01f9d4b0
0xaaae7353d4b0
0xaaabb5c7d4b0
0xaaabd392d4b0
0xaaab0787d4b0
0xaaacdbd4d4b0
0xaaabc8d2d4b0
0xaaab6fafd4b0
0xaaad8ef8d4b0
0xaaab5bccd4b0
0xaaae78f5d4b0
0xaaada9b0d4b0
0xaaacc4afd4b0
0xaaab68dad4b0
0xaaac9fd7d4b0
0xaaab96f6d4b0
0xaaac12a9d4b0
0xaaac2c4bd4b0
0xaaae8aa8d4b0
0xaaac7d59d4b0
0xaaab8f07d4b0
0xaaad17dcd4b0
0xaaabed8dd4b0
0xaaae2a43d4b0
0xaaac133dd4b0
0xaaac5aa1d4b0
0xaaae0e3fd4b0
0xaaac04f5d4b0
0xaaac2861d4b0
0xaaae73ffd4b0
0xaaab6d75d4b0
0xaaae2e1ad4b0
0xaaab7ccbd4b0
0xaaad15a0d4b0
0xaaacaba8d4b0
0xaaab9004d4b0
0xaaae57e6d4b0
0xaaad7265d4b0
0xaaabcc47d4b0
0xaaac8b20d4b0
0xaaadf688d4b0
0xaaad361ed4b0
0xaaabcb51d4b0
0xaaab2894d4b0
0xaaab4494d4b0
0xaaae92e5d4b0
0xaaab8093d4b0
0xaaade01cd4b0
0xaaac9051d4b0
0xaaac3371d4b0
0xaaab94fed4b0
0xaaad70cbd4b0
0xaaacdf29d4b0
0xaaae5b0bd4b0
0xaaac6e4fd4b0
0xaaac9ec5d4b0
0xaaad4e10d4b0
0xaaac4a17d4b0
0xaaae46b5d4b0
0xaaac95acd4b0
0xaaac86cbd4b0
0xaaab57e2d4b0

Evgenii Stepanov via llvm-dev <[hidden email]> writes:

> Could you run the binary a few times and collect different code
> addresses it complains about?
> Could be a change in ASLR randomness.
> It looks like the ranges in aarch64 shadow mapping are unnecessarily
> restrictive.
> I did not test this, but the following seems possible:
> app-14 0x0AAA000000000 .. 0x0AAB000000000
> shadow-14 0x0AAC000000000 .. 0x0AAD000000000
> origin-14 0x0AAD000000000 .. 0x0AAE000000000
>
> On Thu, Oct 25, 2018 at 6:42 AM David Greene via llvm-dev
> <[hidden email]> wrote:
>
>     Adhemerval Zanella via llvm-dev <[hidden email]> writes:
>    
>     > This seems to be printed by InitShadow and it is an
>     initialization routine
>     > which runs on all msan enabled binaries. The only issue I think
>     is runtime
>     > is set __msan_track_origins by -msan-track-origins=1 option and
>     unfortunately
>     > it does not seem to be stressed in any testcase. Is it the case
>     on this binary
>     > you are testing?
>    
>     These are existing tests in the repository. I don't see
>     -msan-track-origins set in the RUN lines so that can't be the only
>     thing
>     that enables this message.
>    
>     -David
>     _______________________________________________
>     LLVM Developers mailing list
>     [hidden email]
>     http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
> _______________________________________________
> LLVM Developers mailing list
> [hidden email]
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] [compiler-rt][msan] msan tests failing on AArch64

Amara Emerson via llvm-dev


On Fri, Oct 26, 2018 at 7:12 AM David Greene <[hidden email]> wrote:
Below are some of the failing addresses for two different tests.  I've
got about 20 or so tests that fail in this way.  Thanks for looking into
this!

Thanks! It looks like my proposed change should help then.

Is there a description somewhere of how these maps are determined?

Mappings need to
1. Match MEM_TO_SHADOW and SHADOW_TO_ORIGIN definitions below. See CheckMemoryLayoutSanity.
2. Cover all possible executable and library locations.

AArch64 mappings have an extra constraint: when trimmed to 39 or 42 bits VMA (by throwing out everything above that) they still need to make sense.
 

> I did not test this, but the following seems possible:
> app-14 0x0AAA000000000 .. 0x0AAB000000000
> shadow-14 0x0AAC000000000 .. 0x0AAD000000000
> origin-14 0x0AAD000000000 .. 0x0AAE000000000

That would seem to agree with the data below, though I never saw 0xaaaf
as a prefix in 10,000 runs.  The highest I ever saw was 0xaaaea.

                          -David


Test 1
0xaaad8cf2d490
0xaaabc698d490
0xaaab7aafd490
0xaaae3aa4d490
0xaaab6ec2d490
0xaaad64a1d490
0xaaac01f7d490
0xaaab057cd490
0xaaae0bb8d490
0xaaadb2fbd490
0xaaae8547d490
0xaaacc277d490
0xaaab704ed490
0xaaada62bd490
0xaaac4737d490
0xaaac76a7d490
0xaaadd1a4d490
0xaaaccbc2d490
0xaaae080dd490
0xaaadc414d490
0xaaad5dedd490
0xaaabb7f5d490
0xaaae4165d490
0xaaab9814d490
0xaaab94dad490
0xaaae124ed490
0xaaac6f82d490
0xaaab7c54d490
0xaaae3e32d490
0xaaae7a48d490
0xaaabf769d490
0xaaae6de9d490
0xaaad7eaed490
0xaaabe97ed490
0xaaabe58fd490
0xaaad363fd490
0xaaae3717d490
0xaaac13e8d490
0xaaad3c45d490
0xaaab4d37d490
0xaaaea00ed490
0xaaadcb95d490
0xaaae1888d490
0xaaab5530d490
0xaaac6a9ed490
0xaaacbe7fd490
0xaaabcc8cd490
0xaaac2701d490
0xaaad01afd490
0xaaad0dadd490
0xaaad7dead490
0xaaab7eb0d490
0xaaac8ed5d490
0xaaae8013d490
0xaaae3be8d490
0xaaacec0bd490
0xaaab6f3cd490
0xaaacbfa1d490
0xaaad8fead490
0xaaabc10bd490
0xaaad9a5ad490
0xaaabecc5d490
0xaaac0802d490
0xaaab00bcd490
0xaaae8b0ed490
0xaaacdc4dd490
0xaaae2cedd490
0xaaadcec2d490
0xaaae0ac6d490
0xaaace326d490
0xaaae39a8d490
0xaaadb117d490
0xaaac32fad490
0xaaabb1c9d490
0xaaaccd47d490
0xaaad17f0d490
0xaaad252fd490
0xaaad7183d490
0xaaab1010d490
0xaaac75ffd490
0xaaae45cbd490
0xaaab9b7cd490
0xaaae41fad490
0xaaadb898d490
0xaaab0589d490
0xaaab9990d490
0xaaac4babd490
0xaaab19a4d490
0xaaae0d16d490
0xaaab6f92d490
0xaaadb5d1d490

Test 2
0xaaae5938d4b0
0xaaab5134d4b0
0xaaad3461d4b0
0xaaabbe42d4b0
0xaaae3d0dd4b0
0xaaade03ad4b0
0xaaac7f14d4b0
0xaaabd7f0d4b0
0xaaae553ed4b0
0xaaac04d7d4b0
0xaaad5b02d4b0
0xaaaea137d4b0
0xaaabdb2cd4b0
0xaaabf431d4b0
0xaaac933ad4b0
0xaaab5564d4b0
0xaaae84c5d4b0
0xaaac2af5d4b0
0xaaacf5ecd4b0
0xaaad7d2bd4b0
0xaaaba9e6d4b0
0xaaae97cfd4b0
0xaaab21d5d4b0
0xaaad6c3bd4b0
0xaaac01f9d4b0
0xaaae7353d4b0
0xaaabb5c7d4b0
0xaaabd392d4b0
0xaaab0787d4b0
0xaaacdbd4d4b0
0xaaabc8d2d4b0
0xaaab6fafd4b0
0xaaad8ef8d4b0
0xaaab5bccd4b0
0xaaae78f5d4b0
0xaaada9b0d4b0
0xaaacc4afd4b0
0xaaab68dad4b0
0xaaac9fd7d4b0
0xaaab96f6d4b0
0xaaac12a9d4b0
0xaaac2c4bd4b0
0xaaae8aa8d4b0
0xaaac7d59d4b0
0xaaab8f07d4b0
0xaaad17dcd4b0
0xaaabed8dd4b0
0xaaae2a43d4b0
0xaaac133dd4b0
0xaaac5aa1d4b0
0xaaae0e3fd4b0
0xaaac04f5d4b0
0xaaac2861d4b0
0xaaae73ffd4b0
0xaaab6d75d4b0
0xaaae2e1ad4b0
0xaaab7ccbd4b0
0xaaad15a0d4b0
0xaaacaba8d4b0
0xaaab9004d4b0
0xaaae57e6d4b0
0xaaad7265d4b0
0xaaabcc47d4b0
0xaaac8b20d4b0
0xaaadf688d4b0
0xaaad361ed4b0
0xaaabcb51d4b0
0xaaab2894d4b0
0xaaab4494d4b0
0xaaae92e5d4b0
0xaaab8093d4b0
0xaaade01cd4b0
0xaaac9051d4b0
0xaaac3371d4b0
0xaaab94fed4b0
0xaaad70cbd4b0
0xaaacdf29d4b0
0xaaae5b0bd4b0
0xaaac6e4fd4b0
0xaaac9ec5d4b0
0xaaad4e10d4b0
0xaaac4a17d4b0
0xaaae46b5d4b0
0xaaac95acd4b0
0xaaac86cbd4b0
0xaaab57e2d4b0

Evgenii Stepanov via llvm-dev <[hidden email]> writes:

> Could you run the binary a few times and collect different code
> addresses it complains about?
> Could be a change in ASLR randomness.
> It looks like the ranges in aarch64 shadow mapping are unnecessarily
> restrictive.
> I did not test this, but the following seems possible:
> app-14 0x0AAA000000000 .. 0x0AAB000000000
> shadow-14 0x0AAC000000000 .. 0x0AAD000000000
> origin-14 0x0AAD000000000 .. 0x0AAE000000000
>
> On Thu, Oct 25, 2018 at 6:42 AM David Greene via llvm-dev
> <[hidden email]> wrote:
>
>     Adhemerval Zanella via llvm-dev <[hidden email]> writes:
>     
>     > This seems to be printed by InitShadow and it is an
>     initialization routine
>     > which runs on all msan enabled binaries. The only issue I think
>     is runtime
>     > is set __msan_track_origins by -msan-track-origins=1 option and
>     unfortunately
>     > it does not seem to be stressed in any testcase. Is it the case
>     on this binary
>     > you are testing?
>     
>     These are existing tests in the repository. I don't see
>     -msan-track-origins set in the RUN lines so that can't be the only
>     thing
>     that enables this message.
>     
>     -David
>     _______________________________________________
>     LLVM Developers mailing list
>     [hidden email]
>     http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
> _______________________________________________
> LLVM Developers mailing list
> [hidden email]
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] [compiler-rt][msan] msan tests failing on AArch64

Amara Emerson via llvm-dev
Evgenii Stepanov via llvm-dev <[hidden email]> writes:

>     Below are some of the failing addresses for two different tests.
>     I've got about 20 or so tests that fail in this way. Thanks for
>     looking into this!
>
> Thanks! It looks like my proposed change should help then.

Great!  Do you want to get something up on Phab and I can test it?

                       -David
_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] [compiler-rt][msan] msan tests failing on AArch64

Amara Emerson via llvm-dev
Sorry, I won't have time for this today.

On Fri, Oct 26, 2018 at 12:24 PM David Greene <[hidden email]> wrote:
Evgenii Stepanov via llvm-dev <[hidden email]> writes:

>     Below are some of the failing addresses for two different tests.
>     I've got about 20 or so tests that fail in this way. Thanks for
>     looking into this!
>
> Thanks! It looks like my proposed change should help then.

Great!  Do you want to get something up on Phab and I can test it?

                       -David

_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] [compiler-rt][msan] msan tests failing on AArch64

Amara Emerson via llvm-dev
Evgenii Stepanov <[hidden email]> writes:

> Sorry, I won't have time for this today.

That's fine.  I just wanted to know whether this is a change you wanted
to make or if you wanted me to make it.  I'm not sure I'm qualified.  :)

                         -David

> On Fri, Oct 26, 2018 at 12:24 PM David Greene <[hidden email]> wrote:
>
>     Evgenii Stepanov via llvm-dev <[hidden email]> writes:
>    
>     > Below are some of the failing addresses for two different tests.
>     > I've got about 20 or so tests that fail in this way. Thanks for
>     > looking into this!
>     >
>     > Thanks! It looks like my proposed change should help then.
>    
>     Great! Do you want to get something up on Phab and I can test it?
>    
>     -David
_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev