On Fri, 28 Jan 2022 04:07:40 GMT, Chris Plummer <cjplum...@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) > > Chris Plummer has updated the pull request incrementally with one additional > commit since the last revision: > > Guard against invalid CodeBlobs that may throw exceptions. Marked as reviewed by kevinw (Committer). Yes, looks good -- I like less asserting or throwing from methods that are trying to make sense of data that may not make perfect sense! ------------- PR: https://git.openjdk.java.net/jdk/pull/7217