JDK-8273109 : runtime/cds/appcds/loaderConstraints/DynamicLoaderConstraintsTest times out
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 18
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2021-08-30
  • Updated: 2021-09-13
  • Resolved: 2021-09-08
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 18
18 b14Fixed
Related Reports
Relates :  
JDK-8273505 - runtime/cds/appcds/loaderConstraints/DynamicLoaderConstraintsTest.java#default-cl crashed with SIGSEGV in MetaspaceShared::link_shared_classes
Relates :  
JDK-8273612 - Fix for JDK-8272873 causes timeout in running some tests with -Xcomp
Relates :  
JDK-8273509 - runtime/cds/appcds/loaderConstraints/DynamicLoaderConstraintsTest.java sub-tests fail with exitValue = 134
Description
No obvious reason in log.
Comments
The fix for this test is in jdk-18+14-755.
09-09-2021
Changeset: ba31eee4 Author: Daniel D. Daugherty <dcubed@openjdk.org> Date: 2021-09-08 18:33:04 +0000 URL: https://git.openjdk.java.net/jdk/commit/ba31eee4fc92bba3657e5f3fec2b85f55120d7a1
08-09-2021
Here's the context diff for a proposed fix: $ git diff diff --git a/test/hotspot/jtreg/runtime/cds/appcds/loaderConstraints/DynamicLoaderConstraintsTest.java b/test/hotspot/jtreg/runtime/cds/appcds/loaderConstraints/DynamicLoaderConstraintsTest.java index 1a7ea7ca2dd..95edc901a35 100644 --- a/test/hotspot/jtreg/runtime/cds/appcds/loaderConstraints/DynamicLoaderConstraintsTest.java +++ b/test/hotspot/jtreg/runtime/cds/appcds/loaderConstraints/DynamicLoaderConstraintsTest.java @@ -33,7 +33,7 @@ * jdk.httpserver * @build sun.hotspot.WhiteBox * @run driver jdk.test.lib.helpers.ClassFileInstaller sun.hotspot.WhiteBox - * @run main/othervm -XX:+UnlockDiagnosticVMOptions -XX:+WhiteBoxAPI -Xbootclasspath/a:. DynamicLoaderConstraintsTest + * @run main/othervm/timeout=180 -XX:+UnlockDiagnosticVMOptions -XX:+WhiteBoxAPI -Xbootclasspath/a:. DynamicLoaderConstraintsTest */ /** @@ -49,7 +49,7 @@ * jdk.httpserver * @build sun.hotspot.WhiteBox * @run driver jdk.test.lib.helpers.ClassFileInstaller sun.hotspot.WhiteBox - * @run main/othervm -XX:+UnlockDiagnosticVMOptions -XX:+WhiteBoxAPI -Xbootclasspath/a:. DynamicLoaderConstraintsTest custom + * @run main/othervm/timeout=180 -XX:+UnlockDiagnosticVMOptions -XX:+WhiteBoxAPI -Xbootclasspath/a:. DynamicLoaderConstraintsTest custom */ import com.sun.net.httpserver.HttpExchange;
08-09-2021
There are currently 17 sightings in Tier7 and Tier8. Here's my analysis of those sightings: jdk-18+13-623-tier8 macos-x64 -Xcomp default-cl timeout-passed@1271 jdk-18+13-623-tier8 macos-x64 -Xcomp custom-cl timeout-failed@1264 jdk-18+13-640-tier7 linux-x64 -Xcomp default-cl timeout-passed@1233 jdk-18+13-640-tier7 linux-x64 -Xcomp custom-cl timeout-failed@1301 jdk-18+13-642-tier8 macos-x64 -Xcomp custom-cl timeout-passed@1292 jdk-18+13-659-tier8 macos-x64 -Xcomp default-cl timeout-failed@1274 jdk-18+13-659-tier8 macos-x64 -Xcomp custom-cl timeout-failed@1275 jdk-18+13-659-tier8 macos-x64 -Xcomp custom-cl timeout-failed@1358 jdk-18+13-677-tier7 linux-x64 -Xcomp default-cl timeout-passed@1279 jdk-18+13-677-tier7 linux-x64 -Xcomp custom-cl timeout-failed@1307 jdk-18+13-677-tier7 linux-x64 -Xcomp custom-cl timeout-passed@1234 jdk-18+14-692-tier7 linux-x64 -Xcomp custom-cl timeout-passed@1262 jdk-18+14-700-tier8 macos-x64 -Xcomp custom-cl timeout-passed@1303 jdk-18+14-700-tier8 macos-x64 -Xcomp custom-cl timeout-failed@1295 jdk-18+14-714-tier8 macos-x64 -Xcomp default-cl timeout-failed@1306 jdk-18+14-714-tier8 macos-x64 -Xcomp custom-cl timeout-failed@1269 jdk-18+14-723-tier7 linux-x64 -Xcomp default-cl timeout-passed@1307 A "timeout-passed" entry means that the test timed out, but passed while the timeout handler was running. A "timeout-failed" entry means that the test timed out, but did NOT pass while the timeout handler was running. There were previously 20 sightings in the JDK18 CI, but when I analyzed those failures I figured out that the failure mode was different than a simple timeout. Please see: JDK-8273505 runtime/cds/appcds/loaderConstraints/DynamicLoaderConstraintsTest.java#default-cl crashed with SIGSEGV in MetaspaceShared::link_shared_classes JDK-8273509 runtime/cds/appcds/loaderConstraints/DynamicLoaderConstraintsTest.java sub-tests fail with exitValue = 134 Since these timeout failure sightings are all with -Xcomp enabled, I think that's why the timeoutFactor == 10. Based on my analysis of the above data, I think we should bump the default timeout value for both of these sub-tests from 120 to 180. That *should* give sufficient time for these tests to pass when -Xcomp is enabled.
08-09-2021
This failure happens now every day. Re-evaluating the priority: MMM --> P3
08-09-2021
[~ccheung] - has something changed recently that is causing these tests to fail? It looks like they first showed up on 2021.08.28 in jdk-18+13-623-tier8... And now they are showing up quite a bit in Tier7 and Tier8...
02-09-2021
ILW = MLM = P4
31-08-2021
The test was run with the following -Xcomp vmoptions in both tiers 7 and 8: -Dtest.java.opts='-Xcomp -XX:+CreateCoredumpOnCrash -ea -esa -XX:CompileThreshold=100 -XX:+UnlockExperimentalVMOptions -server -XX:+TieredCompilation -XX:+DeoptimizeALot' The test contains 2 sub-tests "default-cl" and "custom-cl". Below are the timeout info obtained from the logs. Tier7: default-cl (timeout set to 1200000ms, elapsed time including timeout handling was 1233491ms) custom-cl (timeout set to 1200000ms, elapsed time including timeout handling was 1301765ms) Tier8: (timeout set to 1200000ms, elapsed time including timeout handling was 1271090ms) Custom-cl (timeout set to 1200000ms, elapsed time including timeout handling was 1264831ms) The test has a default timeout of 120s and was run with the timeout factor set to 10. Increasing the timeout to 240s should hopefully fix the problem.
31-08-2021