jdk19 OpenJDK java/lang/Thread/virtual/HoldsLock.java Cannot invoke "java.lang.management.ThreadInfo.getLockInfo()" because "<local17>" is null #16261
Comments
|
@tajila @fengxue-IS fyi |
|
@mikezhang1234567890 Can you please take a look at this? We haven't seen it in a while, if it cant be reproduced please close. |
|
Will take a look. |
|
@tajila Ran a 200x grinder here and it passed, I think this issue can be closed. |
|
closing based on previous comment |
|
This still occurs, reopening. It doesn't seem like a blocker for the Java 19 release however, it can move out. https://openj9-jenkins.osuosl.org/job/Test_openjdk19_j9_sanity.openjdk_x86-64_windows_Nightly/62 |
|
Haven't managed to reproduce the error, but the cause is because I think the createStackTrace here is the likely cause since it looks like the only place that returns |
|
https://openj9-jenkins.osuosl.org/job/Test_openjdk19_j9_sanity.openjdk_x86-64_windows_Nightly/66 |
|
https://openj9-jenkins.osuosl.org/job/Test_openjdk19_j9_sanity.openjdk_x86-64_windows_Nightly/71 |
|
JDK19 internal build( |
|
https://openj9-jenkins.osuosl.org/job/Test_openjdk19_j9_sanity.openjdk_x86-64_windows_Nightly/74 |
|
https://openj9-jenkins.osuosl.org/job/Test_openjdk19_j9_sanity.openjdk_x86-64_windows_Nightly/86/ |
|
I was able to reproduce this with a personal build, this issue seem to be machine/OS dependent as I got 150/150 pass on win2016 machine and 24/48 failure on win11. Failure due to |
|
https://openj9-jenkins.osuosl.org/job/Test_openjdk19_j9_sanity.openjdk_x86-64_windows_Nightly/97/ - win2019-x64-2 |
|
JDK19 internal build( |
|
https://openj9-jenkins.osuosl.org/job/Test_openjdk19_j9_sanity.openjdk_x86-64_windows_Nightly/103 - win2012x64-openj9-1 https://openj9-jenkins.osuosl.org/job/Test_openjdk19_j9_sanity.openjdk_x86-64_windows_Nightly/104 |
|
@fengxue-IS Any progress on this? |
|
Still working on reproducing this locally to get a corefile for investigation |
|
reproduce with corefile, based on tid from the corefile, the problematic id is a value that is already assigned out and terminated. long[] tids = bean.getAllThreadIds();
boolean foundCarrier = false;
for (long tid : tids) {
ThreadInfo info = bean.getThreadInfo(tid); |
|
How is the test being run? Looking at the source, I don't see where the Both the run commands for this test indicate "othervm" which I think means a new VM should be forked to run the test... See https://openjdk.org/jtreg/tag-spec.html Is that not happening? |
|
Re SeedGenerator on Windows, seems related to another problem we've been seeing. I suspect there is an OpenJDK timing bug in the generic SeedGenerator which is causing it to take an excessive amount of time. Probably related to the test machines not being setup correctly to use the (MS Crypto API) native Windows seed generator. Copying my related note below: These specific test(s) timed out. There are two tests but they are both running the ThreadedSeedGenerator. From the output you can see it's running the following code, the test is waiting on this. Adoptium is the same In some of my grinders I collected diagnostics. It's burning a lot of system CPU time (16+ min) running the ThreadedSeedGenerator loop. It's possible the ThreadedSeedGenerator code is somewhat bogus, it looks to me like the loop The code waiting for the random bytes |
|
About the use of the SeedGenerator, if something is calling SecureRandom, that uses the SeedGenerator on Windows. Running on Linux, I set the following option |
|
The test itself is invoked via the following ( |
|
I've re-run the build on a windows 2016 machine which normally don't fail. (https://hyc-runtimes-jenkins.swg-devops.com/view/Test_grinder/job/Grinder/31074/consoleText) With windows 2016, the |
|
I suspect it's related to #16710, i.e. machines where access to the MS Crypto API isn't allowed, otherwise the Window NativeSeedGenerator would be used. Plus the speed of the machines. |
|
How about we just fix the test to check for nulls, in the case where the thread no longer exists. |
I will create a PR to fix the test in the extension repo. |
https://openj9-jenkins.osuosl.org/job/Test_openjdk19_j9_sanity.openjdk_x86-64_windows_Nightly/43
jdk_lang_1
java/lang/Thread/virtual/HoldsLock.java
The text was updated successfully, but these errors were encountered: