SA Debug attach to another jvm version possible?

David Holmes david.holmes at oracle.com
Tue Aug 21 02:17:18 UTC 2018


Hi Sharath,

On 21/08/2018 3:07 AM, Sharath Ballal wrote:
> Hello Egor,
> 
> By default, SA checks for the exact match of the version between the debugger and the debuggee.  If you 

In that case we need to fix the referenced documentation that states 
otherwise.

Cheers,
David

want SA to ignore the version, you need to provide the 
"-Dsun.jvm.hotspot.runtime.VM.disableVersionCheck" option to the java 
launcher from the command line.  This is the case even if you are not 
using the debug server.  However since 'jstack' and similar tools don’t 
take the "-D" option of java, you can invoke it as follows:
> 
> java   -cp <jdk>/lib/sa-jdi.jar   -Dsun.jvm.hotspot.runtime.VM.disableVersionCheck   sun.jvm.hotspot.tools.JStack   localhost
> 
> If you invoke the SA tools with this option, you will get a warning that the version check has been disabled.
> 
> Example:
> $ <jdk>/bin/java -cp <jdk>/lib/sa-jdi.jar -Dsun.jvm.hotspot.runtime.VM.disableVersionCheck sun.jvm.hotspot.tools.JStack localhost
> Attaching to remote server localhost, please wait...
> WARNING: You have disabled SA and VM version check. You may be using incompatible version of SA and you may see unexpected results.
> Debugger attached successfully.
> Server compiler detected.
> JVM version is 25.121-b13
> Deadlock Detection:
> 
> No deadlocks found.
> 
> Thread t@ 2804: (state = BLOCKED)
> 
> 
> Thread t@ 2803: (state = BLOCKED)
>   - java.lang.Object.wait(long) @bci=0 (Interpreted frame)
>   - java.lang.ref.ReferenceQueue.remove(long) @bci=59, line=143 (Interpreted frame)
>   - java.lang.ref.ReferenceQueue.remove() @bci=2, line=164 (Interpreted frame)
>   - java.lang.ref.Finalizer$FinalizerThread.run() @bci=36, line=209 (Interpreted frame)
> 
> 
> Thread t@ 2802: (state = BLOCKED)
>   - java.lang.Object.wait(long) @bci=0 (Interpreted frame)
>   - java.lang.Object.wait() @bci=2, line=502 (Interpreted frame)
>   - java.lang.ref.Reference.tryHandlePending(boolean) @bci=54, line=191 (Interpreted frame)
>   - java.lang.ref.Reference$ReferenceHandler.run() @bci=1, line=153 (Interpreted frame)
> 
> 
> Thread t@ 2798: (state = BLOCKED)
>   - java.lang.Thread.sleep(long) @bci=0 (Interpreted frame)
>   - HelloWorld.main(java.lang.String[]) @bci=72, line=15 (Interpreted frame)
> 
> 
> Hope this helps.
> 
> Thanks,
> Sharath
> 
> 
> -----Original Message-----
> From: Egor Ushakov [mailto:egor.ushakov at jetbrains.com]
> Sent: Monday, August 20, 2018 3:42 PM
> To: serviceability-dev at openjdk.java.net serviceability-dev at openjdk.java.net
> Subject: SA Debug attach to another jvm version possible?
> 
> Hi all,
> 
> documentation for SA Debug Server Attaching Connector here:
> https://docs.oracle.com/javase/8/docs/technotes/guides/jpda/conninv.html#Connectors
> states that the SADebugServer has to run on the same vm version as the debugee process, but "the debugger does not have to be the same bit size and version."
> However any attempts to connect from another version fail with sun.jvm.hotspot.runtime.VMVersionMismatchException.
> 
> Please help, what do I do wrong (locally for simplicity):
> - start the debugee process with jdk1.8.0_162  - get the PID
> - start "jdk1.8.0_162\bin>jsadebugd.exe PID" - all starts well
> - trying to attach jstack, jdb or whatever from another version:
> jdk1.8.0_152\bin>jstack localhost
> Attaching to remote server localhost, please wait...
> Error attaching to remote server:
> sun.jvm.hotspot.runtime.VMVersionMismatchException: Supported versions are 25.152-b16. Target VM is 25.162-b12
> sun.jvm.hotspot.debugger.DebuggerException:
> sun.jvm.hotspot.runtime.VMVersionMismatchException: Supported versions are 25.152-b16. Target VM is 25.162-b12
> 
> jdk1.8.0_152\bin>jdb -connect
> "sun.jvm.hotspot.jdi.SADebugServerAttachingConnector:debugServerName=localhost"
> java.io.IOException
>           at
> sun.jvm.hotspot.jdi.SADebugServerAttachingConnector.attach(SADebugServerAttachingConnector.java:106)
>           at
> com.sun.tools.example.debug.tty.VMConnection.attachTarget(VMConnection.java:519)
>           at
> com.sun.tools.example.debug.tty.VMConnection.open(VMConnection.java:328)
>           at com.sun.tools.example.debug.tty.Env.init(Env.java:63)
>           at com.sun.tools.example.debug.tty.TTY.main(TTY.java:1082)
> Caused by: java.lang.reflect.InvocationTargetException
>           at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>           at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>           at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>           at java.lang.reflect.Method.invoke(Method.java:498)
>           at
> sun.jvm.hotspot.jdi.SADebugServerAttachingConnector.createVirtualMachine(SADebugServerAttachingConnector.java:72)
>           at
> sun.jvm.hotspot.jdi.SADebugServerAttachingConnector.attach(SADebugServerAttachingConnector.java:91)
>           ... 4 more
> Caused by: sun.jvm.hotspot.debugger.DebuggerException:
> sun.jvm.hotspot.runtime.VMVersionMismatchException: Supported versions are 25.152-b16. Target VM is 25.162-b12
>           at sun.jvm.hotspot.HotSpotAgent.setupVM(HotSpotAgent.java:435)
>           at sun.jvm.hotspot.HotSpotAgent.go(HotSpotAgent.java:305)
>           at sun.jvm.hotspot.HotSpotAgent.attach(HotSpotAgent.java:183)
>           at
> sun.jvm.hotspot.jdi.VirtualMachineImpl.createVirtualMachineForServer(VirtualMachineImpl.java:241)
>           ... 10 more
> Caused by: sun.jvm.hotspot.runtime.VMVersionMismatchException: Supported versions are 25.152-b16. Target VM is 25.162-b12
>           at sun.jvm.hotspot.runtime.VM.checkVMVersion(VM.java:227)
>           at sun.jvm.hotspot.runtime.VM.<init>(VM.java:294)
>           at sun.jvm.hotspot.runtime.VM.initialize(VM.java:370)
>           at sun.jvm.hotspot.HotSpotAgent.setupVM(HotSpotAgent.java:431)
>           ... 13 more
> 
> Thanks!
> 
> --
> Egor Ushakov
> Software Developer
> JetBrains
> http://www.jetbrains.com
> The Drive to Develop
> 


More information about the serviceability-dev mailing list