With mainline, classes in the boot classpath that hard fail can happen.
Spotted while reviewing code on verifier.
This is to not abort the runtime for a scenario like:
New code in T, not executed in S (but still shipping on S through a
mainline update), relies on the fact a class that was present in S
moved from 'final' to 'non-final'. When verifying on S, this could
lead to hard failures. But given the class is not supposed to execute,
that's OK.
Test: device booting
Change-Id: I68512858e9085dd45c4f9b77ac3f9dea788d3fa4
diff --git a/runtime/jit/jit.cc b/runtime/jit/jit.cc
index 76cfb5e..bb421e6 100644
--- a/runtime/jit/jit.cc
+++ b/runtime/jit/jit.cc
@@ -913,12 +913,14 @@
LOG(WARNING) << "Could not find " << descriptor;
continue;
}
- ++number_of_classes;
if (linker->VerifyClass(self, /* verifier_deps= */ nullptr, klass) ==
verifier::FailureKind::kHardFailure) {
- DCHECK(self->IsExceptionPending());
- LOG(FATAL) << "Methods in the boot classpath failed to verify: "
- << self->GetException()->Dump();
+ CHECK(self->IsExceptionPending());
+ LOG(WARNING) << "Methods in the boot classpath failed to verify: "
+ << self->GetException()->Dump();
+ self->ClearException();
+ } else {
+ ++number_of_classes;
}
CHECK(!self->IsExceptionPending());
}