Bug ID: JDK-8264775 ClhsdbFindPC still fails with java.lang.RuntimeException: 'In java stack' missing from stdout/stderr

Versions (Unresolved/Resolved/Fixed)

The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.

JDK 17	JDK 18
17 b28Fixed	18Fixed

The following test failed in the JDK 17 CI:

serviceability/sa/ClhsdbFindPC.java#id3

Here's a snippet from the log file:

----------System.err:(35/1847)----------
java version "17-ea" 2021-09-14 LTS
Java(TM) SE Runtime Environment (fastdebug build 17-ea+17-LTS-1382)
Java HotSpot(TM) 64-Bit Server VM (fastdebug build 17-ea+17-LTS-1382, mixed mode)
 stdout: [ + findpc 0x000000fa6b5ff000
Address 0x000000fa6b5ff000: Is of type JavaCallWrapper
];
 stderr: [ + findpc 0x000000fa6b5ff000
Address 0x000000fa6b5ff000: Is of type JavaCallWrapper
]
 exitValue = -1

java.lang.RuntimeException: Test ERROR java.lang.RuntimeException: 'In java stack' missing from stdout/stderr 

	at ClhsdbFindPC.testFindPC(ClhsdbFindPC.java:283)
	at ClhsdbFindPC.main(ClhsdbFindPC.java:305)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:568)
	at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
	at java.base/java.lang.Thread.run(Thread.java:831)
Caused by: java.lang.RuntimeException: 'In java stack' missing from stdout/stderr 

	at jdk.test.lib.process.OutputAnalyzer.shouldMatch(OutputAnalyzer.java:325)
	at ClhsdbLauncher.runCmd(ClhsdbLauncher.java:166)
	at ClhsdbLauncher.runOnCore(ClhsdbLauncher.java:225)
	at ClhsdbFindPC.runTest(ClhsdbFindPC.java:295)
	at ClhsdbFindPC.testFindPC(ClhsdbFindPC.java:213)
	... 7 more

JavaTest Message: Test threw exception: java.lang.RuntimeException: Test ERROR java.lang.RuntimeException: 'In java stack' missing from stdout/stderr

Changeset: 8caeca00 Author: Chris Plummer <cjplummer@openjdk.org> Date: 2021-06-18 20:27:30 +0000 URL: https://git.openjdk.java.net/jdk17/commit/8caeca003e621dd523eb27ef7e7fea0765ceacb6
18-06-2021
This failure has happened in three Tier1 job sets in a row in the JDK18 CI so bumping this from P3 -> P2.
17-06-2021
This failure mode has popped up in a Tier1 job set so bumping from P4 -> P3.
17-06-2021
The test starts with a jstack dump. One of the earlier lines in the dump is something like: "main" #1 prio=5 tid=0x0000029128e75ad0 nid=0x60f4 runnable [0x000000fa6b5ff000] The last address is the "last java SP", although for some reason SA always chooses to mask off the lower 12 bits. The test does a findpc on this address, expecting it to be "in java stack". However, not only is it in the java stack, but it also happens to be the address of a hotspot JavaCallWrapper object that is (or probably was) on the stack, thus the output of findpc is: Address 0x000000fa6b5ff000: Is of type JavaCallWrapper Part of the reason for this is that SA first checks to see if the address points hotspot object, and if not then checks if it is on the stack. However, I don't think we should change that order for the sake of this test. It's probably best that addresses of hotspot objects that are on the java stack are identified by their type, and not just as being on the java stack. I'm not sure why this issue is suddenly happening. Possibly hotspot has changed a bit (either or directly or indirectly) where JavaCallWrapper objects might be found on the stack. In any regard, there is always some risk of a stack address being for a hotspot object, so the test should defend against this. It could do so by checking for "Is of type" in addition to "In java stack"
06-04-2021