Stop checking the PROT_EXEC bit in dexpreopt test.
When the test was written, odex files didn't get unmapped if the runtime
rejects them in some cases (e.g., CLC mismatch). Therefore, we needed
to check the PROT_EXEC flag to ensure that they are valid.
That's not the case anymore. Today, app images do get unmapped if
rejected.
The check on the PROT_EXEC flag has a drawback: if an odex file is
generated with the "verify" compiler filter, it won't contain any code
and therefore won't be mapped with PROT_EXEC. In this case, the test
will report false positives.
Bug: 267540738
Test: atest art_standalone_dexpreopt_tests
Change-Id: I6bcdcb7ccc9c1fff1773b362eaff3fc44c40d46b
diff --git a/test/dexpreopt/dexpreopt_test.cc b/test/dexpreopt/dexpreopt_test.cc
index 9641e0a..eac84f5 100644
--- a/test/dexpreopt/dexpreopt_test.cc
+++ b/test/dexpreopt/dexpreopt_test.cc
@@ -198,12 +198,7 @@
if (pids.size() != 1) {
return Errorf("There should be exactly one `system_server` process, found {}", pids.size());
}
- // Unlike boot images, app images don't get unmapped if the runtime rejects them in some cases
- // (e.g., CLC mismatch). Therefore, we need to check the PROT_EXEC flag to ensure that they are
- // valid.
- // The ODEX files always contain executable code because system server jars are compiled with the
- // "speed" filter.
- return GetMappedFiles(pids[0], ".odex", PROT_EXEC);
+ return GetMappedFiles(pids[0], ".odex", PROT_READ);
}
TEST(DexpreoptTest, ForZygote) {