On Thu, 1 Sep 2022 18:28:58 GMT, Chris Plummer <cjplum...@openjdk.org> wrote:
>> The root cause of this CR is that we are trying to access the java heap >> during the middle of a GC. This particular test is prone to that happening >> since it runs jstack 4 times on the debuggee as it starts up (the debuggee >> is jshell, so it does a lot of initialization on startup). >> >> SA needs to deal with potentially bad references to java objects. These >> might come from VM structs (such as the JavaThread reference to its java >> Thread instance), or a java object reference from a field of another java >> objects. There's always the possibility that these can be invalid. We work >> around this in most of our testing by getting the debuggee into a steady >> state so no GC can be in progress. >> >> For the most part SA is pretty good about dealing with these bad object >> references, and fails gracefully with an exception, but otherwise continues >> to run. However, this test exposed some holes that resulted in (1) way to >> many exception stack traces and (2) exiting the SA tool rather than trying >> to continue. >> >> The main fix is in JavaThread.printThreadInfo() where we now do a better job >> of dealing with exceptions if any of the java objects references are not >> valid. Even without access to the Thread instance, we can still produce a >> stack trace, but it will be missing things like the thread name and >> priority. This is a lot better than just giving up with the first exception. >> >> The other changes are for the most part just improvements in the error >> output, and getting rid of the printStackTrace() that was cluttering up the >> output. > > Chris Plummer has updated the pull request incrementally with one additional > commit since the last revision: > > Minor indent, spelling, and formatting fixes Thanks Dan and Serguei! ------------- PR: https://git.openjdk.org/jdk/pull/10088
