I want to write a simple visualization of a Java program by displaying the program's method calls as branches of a tree. This could be done quite simply by having the program itself tell the visualization what it is doing, but I want to be able to do this with any Java method/class and not just the ones I modify to do so.
What I need is the ability to watch the methods a program calls and what methods are called within that method and so on. Obviously, stack traces provide exactly this functionality:
java.lang.NullPointerException
at MyClass.mash(MyClass.java:9)
at MyClass.crunch(MyClass.java:6)
at MyClass.main(MyClass.java:3)
So I thought about having the program I want to monitor run in a thread and then just look at that thread's stack. However, the thread class does not really support this. It only supports printing the current stack.
Now I, of course, thought of simply changing the PrintStream of the System class so the thread would print its stack into my PrintStream, but this feels kind of wrong.
Is there a better way to do this? Are there any pre-existing classes/methods I can use?
Also, I'm currently downloading the Java source code, to check how exactly the thread class prints its stack so I could maybe subclass thread and imitate the dumpStack() method with my own getStack() method.
Look also at VisualVM, shipped with latest Java releases.
Oh shoot, looking through the source code I noticed the thread class has a method public StackTraceElement[] getStackTrace(), it just wasn't in the documentation I was reading. Now I feel dumb.
So yeah, that seems to be the solution.
One approach might be to use something like BCEL to preprocess the target bytecode to insert calls to your own code on every method entry and exit (probably best to do exit by wrapping the whole method in a try/finally block, to catch exception exits). From this, you can deduce the call tree exactly as it happens.
You could use AspectJ for that. Have a look at this description of exactly your use case.
Have a look at the ThreadMXBean class -- it my provide what you need. Essentially, you:
call ManagementFactory.getThreadMXBean() to get an instance of ThreadMXBean;
call getAllThreadIds() on the resulting ThreadMXBean to enumerate current threads;
call getThreadInfo() to get the top n stack trace elements from a given list of threads.
Related
I have a thread question.
consider the following simple method.
void do_something(){
//access the current thread heap memory content!?
}
And we would call it from different threads, the question is how would I access the called(current) thread heap memory?! just something like eclipse debug mode.
I know this is a weird question and there are much better solutions to accomplish this, but I just want to know.
I also could get the current stack by Thread.currentThread().getStackTrace(), but It's not really a real stack(at least for me) I just expected something like above, but I don't know how!
push str
call method0
pop str
push abc
push cvb
call method2
...
thanks in advance
Heap content is hard to get hold of since the heap implementation is JVM dependent. You can however get hold of such information via the Java Virtual Machine Tools Interface. This is what Eclipse and other debuggers do. Remember that you have to run you application in debugging mode in order to make use of this interface. You can find documentation on Java debugging on the pages of Oracle.
What you describe to be a stack comes closest to Java byte code. It is much easier to get hold of that. (Byte code represents a method implementation.) You can look at ASM which is a framework for reading Java classes. (Byte code operates on top of a stack but it is not one by itself.)
For your information: Java knows different kind of stack
A thread's method stack: Each thread has a stack of methods that were called for this thread were the current method is on top of the stack. If the top method calls another method, this called method is pushed on top of this stack and becomes the new current method.
Each such method has a call stack where values are pushed and poped from during method invocation. In order to add two numbers, for example, you need to push two numbers on this call stack and direct an addition by a specific byte code instruction.
Besides these two most commonly referred Java stacks, a Java virtual machine has several internal stacks such as the native method stack. This is very implementation specific and you normally do not want to mess with this memory area.
If you just want to analyze the normal path a method goes without actually tracing a running method invocation, have a look at ASM. Otherwise, you chose a quite difficult task.
This is my situation:
I am studying a large codebase, running on Java1.7, not very easy to move around, lots of interfaces, deep inheritance trees, lots of threads etc.
I put a breakpoint in some place, but this object is running in a Thread that was spawned somewhere. I need to find that place.
there are too many .run() and .start() hits to look for individually (and to narrow down by the class is difficult too as there are many classes/inheritance (and I don't know the codebase yet)).
So my questions is, is there a way, having a Thread stopped in a breakpoint (intelliJ, but I can use eclipse too) to find out where it was started??
thanks
Maybe you can put breakpoint into Thread.start().
To avoid mutltiple invocation of breakpoint, maybe it make sense to place breakpoint with conditional logic, for example checking global boolean flag. For example, you suspect, that your code invokes right before some event, when event happens, put global flag to true.
No.
I don't think there's a way out of this without some brute force effort.
I would trace back to the Runnable that was started (through the stack trace), then get that class' inheritance and interface hierarchy, then look for run() and start() methods on all those classes. Unless someone has just gone nuts with inheritance, it shouldn't take that long.
Breaking on the code in your object tells you which thread it is and its call stack can tell you which Runnable you should be looking for. I'm assuming you've already gotten this far and that it's not enough to find all the references to this Thread/Runnable. In that case you can write a wrapper class for java.lang.Thread that does an instanceof/type check in the run() and setting your breakpoint there
I think first you have to get the Runnable that is run. That's simple as it's always the first line of your stack trace. (Of course you need the concrete class and not the one that defines the run method.) Once you have the class it should be easy to find the instantiation. Then it should simple to follow to the point where the thread is started. Did I miss something?
I'm working with threads but after a time, most of them stop doing their job. The first thing I thought was a deadlock, but all are with state RUNNING.
I suppose there is an error in my logic or a new characteristic that I not realized and I must handle (it's a webcrawler).
Is it possible to get the current executing method or operation? I want this to see where my threads are trapped.
EDIT: I think that is something I need to handle or there is error in my logic because this happens after a time executing, not imeddiatly after the start.
A debugger is the way to go. This is what they are designed for.
Java debuggers with threading support are built into both the Eclipse and Netbeans IDEs.
Make VM to dump the threads (Ctrl-Break). Find your threads in the list. Look at the topmost stacktrace method. Done.
You can get the current stack trace in Java. You will get an array of StackTraceElement elements.
The first item in the array is the currently executing method.
See the following question for how to get the stack trace:
Get current stack trace in Java
Code might look like:
StackTraceElement[] trace = Thread.currentThread().getStackTrace();
StackTraceElement yourMethod = trace[1];
System.out.println(yourMethod.getMethodName());
You have 2 options:
Use debug to get some understanding that was executed and what not.
Use a lot of logmessages (you can also produce stacktraces in that messages)
Thread dumps are the right solution for the problem. If you want to do it programmatically within the process (some kind of monitoring logic), then java.lang.management.ThreadMXBean provides access to all threads along with their current stacks at the time.
It is, throw an exception, catch it immediately and save the stack. This is about as performant as asking an elephant to fly overseas but it's possible since it sort of extracts the current call stack to something you can work with.
However, are you sure you haven't run into a livelock?
Do you suppose your web crawler program is in a loop processing the same urls. Add some high level logging so each thread writes what it's processing.
A bug in a third party library is causing an infinite loop in a worker thread on a JBoss instance of mine. Do you know of a way to kill this "stuck" thread without restarting the server? We'd like to be able to recover from this until a fix is deployed, preferably without having to restart.
I've seen a few people mention using Thread.interrupt() - if I were to code my own MBean, how would I get a handle to the thread in question in order to interrupt it?
Update: Wasn't able to solve using any of these methods. I did come across another thread about the same issue that had a link to why Thread.stop() is deprecated. Someone else has asked a similar question with similar results. It seems like more sophisticated containers should provide this kind of health mechanism, but I guess their hands are tied w/r/t the JVM.
I had a similar bug (infinite loop) in a 3rd party lib. I ended up applying the fix myself (while waiting for the people from the 3rd party lib to fix their mess) and then I placed the modified .class in my .war, making sure it is loaded before the bogus .class (the bogus one being inside the bogus 3rd party .jar).
It is not nice but it works, see my question here:
Order of class loading from a .war file
What I mean is this: if you have to wait for the people responsible for the 3rd party bugged lib to fix their stuff, you can potentially be waiting a very long time. We couldn't afford that. We needed a fix ASAP. So we ended up applying a patch/hack to their code.
You could for example add a boolean check inside the infinite loop and then forcing the loop to exit when you want the bogus thread to "die".
Note that I haven't used the deprecated Thread stop() since ten years and I really didn't want to use it in the above case.
I suppose the most difficult part is to identify the hanging thread. You provide no info about it, but perhaps you can build some rules around the thread's name or its current stack trace.
If you can identify the thread by its name, I would get all threads in the VM by getting my own thread group with Thread.currentThread().getThreadGroup(), then walk up the thread group hierarchy by calling getParent() on the thread group until it returns null. You now have the top level thread group. You can now fill a preallocated array with all threads using the enumerate(Thread[] list) method on the top level thread group.
If you need the stack traces anyway to identify the thread, you can also use the static utility method Map<Thread,StackTraceElement[]> Thread.getAllStackTraces() to get all threads. Computing the stack traces is however quite expensive, so this might not be the best solution if you don't actually need them.
After identifying the thread you must call the stop() method on it. Interrupting it won't help, unless the implementation of the running code actually evaluates the thread's interrupted flag and behaves as you expect it to. Not that the stop() method is deprecated and that using it may have many funny side effects. You can find more details in the API documentation.
You could use the discouraged myThread.stop() method. But then it is very likely the Thread is still referenced there, so you should use some reflection magic to remove all references to this thread from the components holding it.
How to find the Thread? Use Thread.getThreadGroup() and ThreadGroup.getThreadGroup() to go up to the root ThreadGroup(), and then use the iterate() functions to go through all threads.
Try my jkillthread which tries to do something like this.
I am trying to debug some C/Java bindings that use some custom refcounting/locking. I would like to have the JVM print a message every time a given object has its monitor entered or exited. Is there any way to do this? Basically, I want this:
synchronized(lock) {
...
System.out.println("hi");
...
}
to print this:
*** "lock" monitorenter
hi
*** "lock" monitorexit
I have looked at the XX options and found nothing. This is OpenJDK 6.
Good question. The only solution I could come up with is basically this:
Use a custom class-loader and preprocess the files with using a bytecode manipulation library such as ASM. (ASM has a good example of how to work with bytecode rewriting in class loaders.)
Then simply add a call to System.out.println before each monitorenter and monitorexit.
Thanks to the nice visitor pattern in the ASM library, this shouldn't be more than a screen or two of code.
Trying to debug a concurreny issue with creative uses of print statements is a losing battle, as your print statements could have their own concurrency bug and not print in the order you expect. Trying to debug or println your way out of a concurreny bug may sound good, but I don't think it will get you the result you want. You need to use careful thinking and logic to reason that your code is correct (more Computer Science than Software Engineering).
Concurrency issues are very hard. If you haven't read Concurrency in Practice, make sure you go read it. Then look at all the possible ways that your synchronized block can be reached, all the things it can change that are outside the scope of the lock, etc.
This would be a perfect situation to use dTrace.
Unfortunately that requires Solaris or OS X.
Fortunately OpenSolaris can still be downloaded and run in a virtual machine. It runs best in VirtualBox.
I don't believe there is a way to bind to a "locking" event in java. But you can look into java.lang.management for various locking information. For example, there is ThreadMXBean.findDeadlockedThreads()
Unless you write your own locking class (or modify the existing one) my guess is that it would be rather difficult to do what you want, specially if you are using a synchronized block over a monitor object and not a Lock class. However you can use the jstack command supplied with the JDK to analyze your process at runtime, check here for the man page, and also there is the JVM option -XX:-PrintConcurrentLocks for printing your locks if you stop your JVM process using Ctrl-Break (more options here).
I will suggest you to implement existing implementation of Lock class or implement one of you own (http://download.oracle.com/javase/tutorial/essential/concurrency/newlocks.html).
Now you can override the lock and unlock method. So instead of using synchronized methods/statements make use of this facility and in lock/unlock methods put your logging :)