This is an archive of the discontinued LLVM Phabricator instance.

[msan] Tentative fix for failing aarch64 test
AbandonedPublic

Authored by cryptoad on Aug 28 2018, 9:12 AM.

Details

Summary

Follow up to a discussion in post D50940 commit.

http://lab.llvm.org:8011/builders/clang-cmake-aarch64-full/builds/5703/steps/ninja%20check%202/logs/FAIL%3A%20MemorySanitizer-AARCH64%3A%3A%20mmap.cc

0xf00000000 appears to be a valid mapping on aarch64 now. Add it to the list of
app address mappings in the mmap.cc test. Reformat the list a bit as well so
that all the addresses are easier to read.

I can't test this, for all I know lower mappings might also work now and that
might require a couple of iterations. If someone can verify that this solves the
issue at hand, please go ahead!

Event Timeline

cryptoad created this revision.Aug 28 2018, 9:12 AM

Could I please get a LGTM and/or other options so that I can try and fix the aarch64 bots?

Looking at msan.h, 0x000F00000000 is not a valid mapping address:

{0x00000000000ULL, 0x01000000000ULL, MappingDesc::INVALID, "invalid"},

Something's broken.

Something's broken.

Interesting. Do you see anything in https://reviews.llvm.org/D50940 that could have lead to this?

I wonder if ProtectMemoryRange in msan_linux.cc needs updating?

I wonder if ProtectMemoryRange in msan_linux.cc needs updating?

Very good point! I guess now that it returns null on error, differentiating with mapping 0 success isn't working out.

cryptoad abandoned this revision.EditedAug 29 2018, 12:35 PM

Reverting the initial patch with D51451.
Abandoning this.