Perform reverify with shared mutator-lock.
Despite comments that seemed to indicate otherwise the verifier is not
capable of running with a strong mutator-lock in all circumstances.
Specifically it relies on being able to allocate exceptions in a
number of situations (for example when a field could not be found but
the class could). This could lead to problems when trying to
reverify a class. To fix this we changed the reverify step to happen
outside of the strong mutator-lock and instead temporarily mark the
redefined methods with every verifier fail flag. The new verification
will then be performed and the flags reset (after suspending
everything).
This also fixes a related issue where performing the verification
with an exclusive mutator lock changed how elements in the dex-cache
were populated, causing the dex-cache to break invariants about
methods always having their classes be present. This could cause
crashes in some circumstances (for example test 1990).
Test: ./test.py --host
Test: go/lem
Bug: 142876078
This partially reverts commit b1eebde9469914ad634a6dc3746ddfb222595609
This partially reverts commit db55a1121b2437765e732c8bbedf914f8a52f624
Change-Id: I0f1e8c47118cc84c8f23c4068944069ac74f5ea3
diff --git a/test/knownfailures.json b/test/knownfailures.json
index 1e00c3f..2e34943 100644
--- a/test/knownfailures.json
+++ b/test/knownfailures.json
@@ -1139,7 +1139,10 @@
"1984-structural-redefine-field-trace",
"1985-structural-redefine-stack-scope",
"1986-structural-redefine-multi-thread-stack-scope",
- "1987-structural-redefine-recursive-stack-scope"
+ "1987-structural-redefine-recursive-stack-scope",
+ "1989-transform-bad-monitor",
+ "1990-structural-bad-verify",
+ "1992-retransform-no-such-field"
],
"variant": "jvm",
"description": ["Doesn't run on RI."]