Hi Jini, for that particular case, it just provides a simple way to reproduce more general problems in SA: first I run a program under gdb and with the option "-XX:CompileCommand=print,...", then I put a breakpoint at a particular place that I suspect the stack walker code has problems with. When the breakpoint hits, I do gcore in gdb and then have a core file to reproduce the problem with jstack or jdb using SACoreAttachingConnector etc. In this particular case I just enter the jdb "locals" command.
The more general thing that I'm doing with the SA code (not sure what is defined as SA and what is SA-JDI but I think the classes I use are still there in Java 9, just harder to access) and that I mentioned to Andrew once and who probably thinks I'm nuts is to use it to effectively debug a java application under gdb. So it's a bit like the attaching to a live process situation using the pid (or a core file for that matter). The nature of our application means that we can't attach to the normal JDWP agent inside the JVM - we have to use gdb and cannot modify the state of the running JVM. I know the code I'm using is a bit fuzzy and imprecise - AMD64CurrentFrameGuess is a prime example that I've had to improve - but fuzzy is actually enough most of the time. Cheers, David On Sat, 2 Feb 2019 at 02:51, Jini George <[email protected]> wrote: > > Hi David, > > This got removed in JDK-9 as a part of SA-JDI removal. > (https://bugs.openjdk.java.net/browse/JDK-8158050). Could you let us > know as to why are you using SA-JDI ? > > Thanks, > Jini. > > On 2/1/2019 9:56 PM, David Griffiths wrote: > > Had a nice simple little reproduction test, went to try it on Java 9 > > and... oh no, sun.jvm.hotspot.jdi.SACoreAttachingConnector has > > disappeared! Has it gone for good? > > > > Cheers, > > > > David > > > > On Wed, 30 Jan 2019 at 10:38, Andrew Haley <[email protected]> wrote: > >> > >> On 1/30/19 10:00 AM, David Griffiths wrote: > >>> I'm not sure this works though for the frame at the top of the stack. > >>> The pushing of the registers that you mention appears to take place in > >>> the updateRegisterMap method which is called when getting the sender. > >>> At the top of the stack the register will be live and not saved > >>> anywhere? > >> > >> No the pushing of the register happens in generated code. > >> > >>> Whatever, I'm seeing a NPE caused by a location that has > >>> WHERE_IN_REGISTER and a register number of 16 that doesn't have > >>> locationValid set in the map. If I modify createStackValue to check > >>> valueAddr being null then it avoids the NPE and getLocals then returns > >>> all the locals except for the one held in a register (the other ones > >>> are on the stack). Not sure what a register number of 16 equates to on > >>> x86, is that supposed to correspond to "not set" or something? > >> > >> You're not helping. Are you sure you've got an up-to-date HotSpot > >> checkout? You're not falling over bug 8217407? > >> > >> -- > >> Andrew Haley > >> Java Platform Lead Engineer > >> Red Hat UK Ltd. <https://www.redhat.com> > >> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
