Currently I have a simple Java program:
public class Test {
public static void main(String[] args) {
boolean test = true;
while (test) {
System.out.println("Hello World");
try { Thread.sleep(1000); } catch (Exception e) {}
}
System.out.println("Bye-bye");
}
}
It prints "Hello World" every second. I would like to use gdb to attach to the process and make a memory patch to stop it with "Bye-bye" printed.
I know GDB can get created VMs (JNI_GetCreatedVMs) from its console, the env object is also available via the API of GetEnv. How can I find the test
variable address in JVM and set it to false (this is optional) to make the program exit normally? Not sure if API like AttachCurrentThread, class like HotSpotVirtualMachine, tools like jmap or jstack can help?
And there is no debug option, assume the simple program running in production with java -cp . Test
.
Thanks in advance for any guidance. :)
additional info (track state)
jmap -dump:file=hex <pid> && jhat hex
and browse at http://localhost:7000; cannot find any reference totest
(it is not an object and just an instance ofclass Z
)jstack <pid>
can get the tid of main thread (0x7fa412002000) andjhat hex
has the object of the java.lang.Thread of main (0x76ab05c40)java.lang.Thread
has a native methodstart0
which invokes hotspot method ofJVM_StartThread
(hotspot/src/share/vm/prims/jvm.cpp), there is a classJavaThread
may contain the memory structure for local variables in thread stack.- if
private static boolean test = true;
; thenJNI_GetCreatedJavaVMs ==> jvm
,jvm->jvm_api->AttachCurrentThread ==> env
,env->env_api->(FindClass, GetStaticFieldID, SetStaticBooleanField) ==> test[true ==> false]
In some cases it is possible to get local variable addresses using HotSpot Serviceability Agent. I've made a sample agent that prints extended stack traces with local variable info:
To run it:
This will attach to Java process
PID
and print the stacktraces likeHere
main
is Java thread name;30920
is native thread ID;@ 15
is bytecode index.The line
[1] 0x00007f075a857910 = (int) 0x1
means that the local variable #1 is located at address 0x00007f075a857910 and has the value 1. This is exactly the variable you are interested in.The local variable information is reliable for interpreted methods, but not always for compiled methods. However, compiled methods will have an extra line with an address of the code, so you can disassemble and inspect it in gdb.