Bug ID: JDK-8281614 serviceability/sa/ClhsdbFindPC.java fails with java.lang.RuntimeException: 'In code in NMethod for jdk/test/lib/apps/LingeredApp.steadyState' 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 19
19 b12Fixed

Seeing the following failure in the Loom repo.

java.lang.RuntimeException: Test ERROR java.lang.RuntimeException: 'In code in NMethod for jdk/test/lib/apps/LingeredApp.steadyState' missing from stdout/stderr 
	at ClhsdbFindPC.testFindPC(ClhsdbFindPC.java:306)
	at ClhsdbFindPC.main(ClhsdbFindPC.java:328)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
	at java.base/java.lang.reflect.Method.invoke(Method.java:577)
	at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:142)
	at java.base/java.lang.VirtualThread.run(VirtualThread.java:270)
	at java.base/java.lang.VirtualThread$VThreadContinuation.lambda$new$0(VirtualThread.java:155)
	at java.base/jdk.internal.vm.Continuation.enter0(Continuation.java:349)
	at java.base/jdk.internal.vm.Continuation.enter(Continuation.java:342)

Note this is not the same as JDK-8269881, which can potentially produce this same failure message. The difference is that for this CR, the stack dump of the SteadyStateThread is present. For JDK-8269881 it is not. The reason it is failing is because for some reason LingeredApp.steadyState is not compiled anymore, even though we run with -Xcomp

"SteadyStateThread" #14 prio=0 tid=0x0000fffbd43d3a50 nid=1523267 waiting for monitor entry [0x0000fffba9b0e000]
   java.lang.Thread.State: UNKNOWN
   JavaThread state: _thread_blocked
 - jdk.test.lib.apps.LingeredApp.steadyState(java.lang.Object) @bci=8, line=537, pc=0x0000fffbbc593fac, Method*=0x0000fffba0403638 (Interpreted frame)
	- waiting to lock <0x00000000c1d0f970> (a java.lang.Object)
 - jdk.test.lib.apps.LingeredApp$1.run() @bci=4, line=543, pc=0x0000fffbbcde5ac8, Method*=0x0000fffba0403eb0 (Compiled frame [deoptimized])

hsdb> + findpc 0x00007fb79c5dda75
Address 0x00007fb79c5dda75: In interpreter codelet: monitorenter [0x00007fb79c5dd9c8, 0x00007fb79c5ddbe0)  536 bytes  

This happens with the following variant of the test:
  serviceability/sa/ClhsdbFindPC.java#xcomp-core

Changeset: a6610031 Author: Chris Plummer <cjplummer@openjdk.org> Date: 2022-02-23 22:55:39 +0000 URL: https://git.openjdk.java.net/jdk/commit/a6610031e2816156fa14876457e260282a88d478
23-02-2022
A pull request was submitted for review. URL: https://git.openjdk.java.net/jdk/pull/7542 Date: 2022-02-19 04:00:30 +0000
19-02-2022
Actually JDK-8242168 was applied right, but there were only two test cases at the time. Both were process test cases (not core file), one with xcomp (and the "@requires vm.opt.DeoptimizeALot != true ") and one without. When the two additional core files test cases were added, the copy-n-paste of the original two test cases was not done properly, and the @requires went on the #no-xcomp-process rather than the #xcomp-process.
19-02-2022
Looks like JDK-8242168 was not applied properly. It was suppose to address this issue, but should have done so for the two xcomp variants, not the two process variants.
19-02-2022
Of the 4 test variants: * @test id=xcomp-process * @test id=xcomp-core * @test id=no-xcomp-process * @test id=no-xcomp-core The two "process" versions have the following: * @requires vm.opt.DeoptimizeALot != true So this explains why it fails with xcomp-core but not xcomp-process. It's not even run with xcomp-process.
19-02-2022
The issue is that the test task is being run with -XX:+Deoptimize a lot, and this is being passed along to the spawned LingeredApp process. Filtering out this option when spawning the LingeredApp process should fix this issue.
19-02-2022