RFR: 8280601: ClhsdbThreadContext.java test is triggering codecache related assert in PointerFinder.find()

[Chris Plummer]

On Tue, 25 Jan 2022 22:07:37 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> It's possible for an address to be in the codecache but not in any CodeBlob. Don't assert in this case.
> 
> Also I ran into a couple of other asserts listed below. It looks like since dumping the threadcontext can result in using PointerFinder with fairly random addresses, it is doing a much better job of stress testing PointerFinder than is done by other tests. The root issue in all these asserts is that a random address in the codecache can either be outside of any CodeBlob, or can map to a CodeBlob that is not yet initialized or could even have been freed. PointerFinder and PointerLocation need to be prepared to handled these asserts, and any other exception thrown. 
> 
> sun.jvm.hotspot.utilities.AssertionFailure: found wrong CodeBlob
> at jdk.hotspot.agent/sun.jvm.hotspot.utilities.Assert.that(Assert.java:32)
> at jdk.hotspot.agent/sun.jvm.hotspot.code.CodeCache.findBlobUnsafe(CodeCache.java:140)
> at jdk.hotspot.agent/sun.jvm.hotspot.utilities.PointerFinder.find(PointerFinder.java:138)
> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.JavaThread.printThreadContextOn(JavaThread.java:493)
> at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor$46.doit(CommandProcessor.java:1702)
> at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:2215)
> at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:2185)
> at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.run(CommandProcessor.java:2056)
> at jdk.hotspot.agent/sun.jvm.hotspot.CLHSDB.run(CLHSDB.java:112)
> at jdk.hotspot.agent/sun.jvm.hotspot.CLHSDB.main(CLHSDB.java:44)
> at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runCLHSDB(SALauncher.java:281)
> at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:500)
> 
> sun.jvm.hotspot.utilities.AssertionFailure: Should have found CodeBlob
> at jdk.hotspot.agent/sun.jvm.hotspot.utilities.Assert.that(Assert.java:32)
> at jdk.hotspot.agent/sun.jvm.hotspot.utilities.PointerFinder.find(PointerFinder.java:140)
> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.JavaThread.printThreadContextOn(JavaThread.java:493)
> at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor$46.doit(CommandProcessor.java:1702)
> at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:2215)
> at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:2185)
> at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.run(CommandProcessor.java:2056)
> at jdk.hotspot.agent/sun.jvm.hotspot.CLHSDB.run(CLHSDB.java:112)
> at jdk.hotspot.agent/sun.jvm.hotspot.CLHSDB.main(CLHSDB.java:44)
> at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runCLHSDB(SALauncher.java:281)
> at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:500)

I ran across a couple more asserts due to what are essentially invalid pointers into the code cache. They look like allocated CodeBlobs, but could be partially initialized, or I think even deleted (or in the process of being deleted). PointerFinder and PointerLocation need to deal with asserts and exceptions that can result from this. The latest changes cover that. Changes are significant enough that I need to have everyone re-review. Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7217