RFR 8222936: mlvm/anonloader/stress/randomBytecodes/Test.java fails due to "ERROR: There were 1 hangups during parsing."
coleen.phillimore at oracle.com
coleen.phillimore at oracle.com
Fri May 31 15:43:54 UTC 2019
Yes, this seems reasonable. Thanks for having this test leave
breadcrumbs if it times out in jtreg.
Coleen
On 5/30/19 2:35 PM, Harold Seigel wrote:
> Hi,
>
> Please review this fix for bug JDK-8222936.
>
> Test .../randomBytecodes/Test.java uses StressClassLoadingTest.java to
> go through 1000's of iterations where it creates and starts a thread
> and waits 10 seconds. The thread tries to load a class whose bytes
> are potentially randomized. If the created thread is still alive
> after 10 seconds then the test saves the randomized class and records
> a hang failure. It then repeats the process for the next iteration.
>
> This test fails about once a month with a hang failure. These appear
> to be invalid failures because the hangs cannot be reproduced with the
> saved randomized class and because the stack traces of the hanging
> threads are empty. Perhaps it just took more than 10 seconds for the
> thread to start because of lack of machine resources?
>
> This change prevents the invalid failures by blocking the entire test
> until either the test fails with a timeout or the loading thread
> finishes, even if it takes more than 10 seconds.
>
> Open Webrev:
> http://cr.openjdk.java.net/~hseigel/bug_8222936/webrev/index.html
>
> JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8222936
>
> StressClassLoadingTest.java is used by three tests,
> .../randomBytecodes/Test.java, .../byteMutation/Test.java, and
> .../parallelLoad/Test.java. The fix was tested by running the three
> tests one thousand times on Linux x64 and a few times on Solaris,
> Windows, and Mac OS X.
>
> Thanks, Harold
>
More information about the hotspot-runtime-dev
mailing list