Hi David,
Thank you for the explanation. From Java 9, there is the 'jhsdb' tool
provided with the JDK, with which you can use the SA features. So, in
this case, you can run it thus to see if you can reproduce the problem:
jhsdb jstack --core <your core file that you dumped with gcore> --exe
<the java launcher path>
Thanks,
Jini.
On 2/2/2019 2:59 PM, David Griffiths wrote:
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
