On Tue, 30 Aug 2022 23:29:18 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 > refernces, 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. Ping. This one is causing quite a bit of noise in our CI, so I would like to get it pushed soon. Thanks! ------------- PR: https://git.openjdk.org/jdk/pull/10088
