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