-
Notifications
You must be signed in to change notification settings - Fork 720
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Windows JDK8 jvmti tests failed with "NPT ERROR: Cannot open library" #2129
Comments
Notice that there are nightly builds whose commits are more advanced than the PRs that failed the tests. I downloaded one nightly build and tried the same tests on my laptop and can't reproduce the error. Since we don't archive builds for PRs, I have no chance to test the failing builds. I tried running the test on my laptop with |
A few builds are kept as attachments to the build jobs. You'll need to grab it quickly after a failure occurs. I couldn't find a failed job that was still available, but as an example see the "Build Artifacts" of https://ci.eclipse.org/openj9/job/Build-JDK8-win_x86-64_cmprssptrs/84/ |
According to @AdamBrousseau, we don't keep the builds for PR's jenkins test. I didn't find any link to the failing build in the failing PRs. The "Build Artifacts" of this failing build contains only the result of the tests. https://ci.eclipse.org/openj9/job/PullRequest-Extended-JDK8-win_x86-64_cmprssptrs-OpenJ9/3/ The latest nightly build is more advanced than the failing PRs, however, the failure is not reproducible on the nightly builds. Thus the failure is not caused by any jit/gc/vm commits. I think the problem is either in machine, testing or packaging process, with the last one being the most likely. If anyone can provide me a failing build, I'd love to test it on my laptop. |
You need to look at the "Build" job which created the JVM used by the Extended test job. |
Maybe I was looking at the wrong type of builds. |
To be clear, the jvmti_extended tests should be renamed (no tests should contain the level they belong to), especially since they are tagged as sanity tests, so you'd look to see what JVM is used by the nightly sanity test job. I believe the some tests are failing because they are running with compressedrefs commandline parameters against a nocompressedrefs build. |
This should result in an error from the VM from which the problem should be obvious #1777 (comment) |
I think @liqunl was having troubles getting an sdk that could produce the error since the nightly is the only ones we archive and the error was never seen in the nightly. If your PR is still seeing this error we could hack the Jenkins files in your PR in order to archive the sdk for your build. PM me if you want to discuss going this route. |
My PR has been merged. I want to clarify that, this is not caused by any PR that has failed the test. The reason being:
Correct me if I'm wrong, it looks like the failing tests have never passed in a PR build since they were added. I think we need to understand why this error only occurs in PR builds but not nightly/continuous builds or internal personal builds, i.e. what's different in the PR builds. It can be the machine, the testing environment, or the resulting jdk. All in all, I think we need someone from the test or infra team to take a look at this issue based on it's nature. I tried my best last Friday, but I can't help if it is not a jit issue. |
Possible solution - Create a link to libnpt.so in $JAVA_HOME/jre/lib from /usr/local/lib The above solution works on FreeBSD. For Windows, Adam said that the nightly builds work fine. But,
|
Not related to the failure, but the test level is wrong. It should be in |
Also seen |
- disable cmdLineTester_jvmtitests_extended on win until eclipse-openj9#2129 is fixed - rename cmdLineTester_jvmtitests_extended to cmdLineTester_jvmtitests_debug Issue: eclipse-openj9#2129 eclipse-openj9#2147 [ci skip] Signed-off-by: lanxia <lan_xia@ca.ibm.com>
- disable cmdLineTester_jvmtitests_extended on win until eclipse-openj9#2129 is fixed - rename cmdLineTester_jvmtitests_extended to cmdLineTester_jvmtitests_debug Issue: eclipse-openj9#2129 eclipse-openj9#2147 [ci skip] Signed-off-by: lanxia <lan_xia@ca.ibm.com>
Remove compressedrefs directory from sun.boot.library.path. Our extensions expect this property to have only one path. See full description in eclipse-openj9#2129. Fixes: eclipse-openj9#2129 Signed-off-by: Theresa Mammarella <Theresa.T.Mammarella@ibm.com>
Fixes: eclipse-openj9/openj9#2129 Signed-off-by: Theresa Mammarella <Theresa.T.Mammarella@ibm.com>
Fixes: eclipse-openj9/openj9#2129 Signed-off-by: Theresa Mammarella <Theresa.T.Mammarella@ibm.com>
Judging from the giant list of references above it seems we are hitting this issue every single time we launch a build. This seems like a high priority issue to me. @pshipton @AdamBrousseau any leads as to what is causing it or potential workarounds? If not we should disable the tests until we get this fixed IMO. |
Yes this has a 100% failure rate in PR builds but 0% in the nightly build. I doubt we want to disable the tests that are causing the failure since it passes in the nightly. Theresa has indicated above why it is failing. I'm not sure if there is a status update on a possible solution. We could disable the windows PR builds but its likely desirable to have windows testing even if there's a known issue with some of the tests. |
The fix is ibmruntimes/openj9-openjdk-jdk8#106 but its not ready to merge yet and won't be until next week unless somebody else wants to address the review comments. |
The immediate problem is fixed (for Windows) by ibmruntimes/openj9-openjdk-jdk8#107. Opened #2547 to handle remaining platforms and other jdk versions. |
- eclipse-openj9#2129 is fixed Signed-off-by: Keith W. Campbell <keithc@ca.ibm.com>
https://ci.eclipse.org/openj9/job/PullRequest-Sanity-JDK8-win_x86-64_cmprssptrs-OpenJ9/36/tapResults/
https://ci.eclipse.org/openj9/job/PullRequest-Sanity-JDK8-win_x86-64_cmprssptrs-OpenJ9/48/tapResults/
Error message:
Failing tests are
The text was updated successfully, but these errors were encountered: