testDDRExt_General failed in OpenJ9 SDK

[Yuehan-Lin]

When importing the DDR tests, DDR general test (testDDRExt_General_openj9) passed on IBM SDK from vmfarm, but did not passed on OpenJ9 SDK.

Failure link

https://ci.adoptopenjdk.net/view/Test_grinder/job/Grinder/1249/
If the link cannot be opened:

• buildlist: functional/DDR_Test
• OS/architecture: linux_x86-64_cmprssptrs
• OpenJDK version:

openjdk version "1.8.0_202-internal"
OpenJDK Runtime Environment (build 1.8.0_202-internal-201903130430-b08)
Eclipse OpenJ9 VM (build master-6259e9f2e, JRE 1.8.0 Linux amd64-64-Bit Compressed References 20190313_249 (JIT enabled, AOT enabled)
OpenJ9   - 6259e9f2e
OMR      - da32e2b9
JCL      - 9dc1c4d81c based on jdk8u202-b08)

Failure output

Output from Grinder: test name: testDDRExt_General_openj9

[AutoRun] [INFO] Starting testWhatis(j9vm.test.ddrext.junit.TestDDRExtensionGeneral)
[java] [DDRExtTesterBase] [ERROR] '!walkinterntable  4' output does not contain success key : WALKING LOCAL INTERN HASHTABLE
[java] [DDRExtTesterBase] [ERROR] '!walkinterntable  4' output :HeadNode is null

Then I tried to test locally using IBM SDK from vmfarm and Openj9 nightly build, after typing !walkinterntable 4 in each jdumpview core,
IBM SDK gives: WALKING LOCAL INTERN HASHTABLE COMPLETED
Nightly Openj9 SDK build gives:HeadNode is null

The IBM SDK from vmfarm

java version "1.8.0_201"
Java(TM) SE Runtime Environment (build 8.0.6.0 - pxa6480sr6-20181206_03(SR6))
IBM J9 VM (build 2.9, JRE 1.8.0 Linux amd64-64-Bit Compressed References 20190115_407521 (JIT enabled, AOT enabled)
OpenJ9   - a4fe0b0
OMR      - 327dfe0
IBM      - e2996d1)
JCL - 20181121_01 based on Oracle jdk8u201-b05

OpenJ9 nightly build

openjdk version "1.8.0_202-internal"
OpenJDK Runtime Environment (build 1.8.0_202-internal-201903130430-b08)
Eclipse OpenJ9 VM (build master-6259e9f2e, JRE 1.8.0 Linux amd64-64-Bit Compressed References 20190313_249 (JIT enabled, AOT enabled)
OpenJ9   - 6259e9f2e
OMR      - da32e2b9
JCL      - 9dc1c4d81c based on jdk8u202-b08)

[pshipton]

@keithc-ca

[keithc-ca]

I tried this test locally on a zLinux system: that test passes for me.
I don't expect the results to be different on xLinux, but I'll try.

[keithc-ca]

Same results on xLinux.

$ ./j2sdk-image/bin/java -version
openjdk version "1.8.0_202-internal"
OpenJDK Runtime Environment (build 1.8.0_202-internal-keithc_2019_03_18_17_06-b00)
Eclipse OpenJ9 VM (build master-f6ba273, JRE 1.8.0 Linux amd64-64-Bit Compressed References 20190318_000000 (JIT enabled, AOT enabled)
OpenJ9   - f6ba273
OMR      - 9b73e2b
JCL      - 6894a18 based on jdk8u202-b08)

[keithc-ca]

I tried to test a build using the same SHAs as reported in the description, but I got no response from testmgmt.stage1.mybluemix.net (see [1]). Is there another way to get those resources?

[1] https://github.com/eclipse/openj9/blob/89bc12b73b47d2c94ae1352b7c71a1c3286f6b7c/test/TestConfig/scripts/testKitGen/makeGenTool/mkgen.pl#L77

[smlambert]

When that service is not available we automatically fall back to use ottawa.csv and modes.xml files from the repo. In other words, we use the resources in https://github.com/eclipse/openj9/tree/master/test/TestConfig/resources.

[keithc-ca]

It doesn't appear to be working that way; instead curl returns an error and configuration terminates incomplete (no jvmtest directory is created).

[smlambert]

FYI @llxia @renfeiw

[llxia]

• the test change is not checked in yet (PR Added DDRtest #5137). The code in master does not have the reported issue.
• regarding this issue testDDRExt_General failed in OpenJ9 SDK #5089 (comment), all openj9 and Adopt builds work fine without modes service. If you can provide error msg, we could look into it. But I think maybe it is easier to debug once we have PR Added DDRtest #5137 delivered.

[keithc-ca]

It would have been helpful to know that this issue only arises in the presence of #5137.

[keithc-ca]

The failure was observed on a virtual system running without access to IBM's internal network. Given this is an open source project, that should be a reasonable use case.

[keithc-ca]

I managed to get a troublesome core file generated where the output of !walkinterntable 4 includes HeadNode is null. I'm trying to understand how and why that string intern table seems to be empty.

[keithc-ca]

I believe the underlying issue here is that the core file is generated from a command that loads everything from the shared class cache. See #5175.

[llxia]

Close this issue as it is fixed.