I use jdb for my Java development. For my application I have two classes: WordUniverseTest and WordUniverse, and the main method is contained in WordUniverseTest. When I execute WordUniverseTest inside of jdb, I construct a WordUniverse object called obj inside of the main method.
But I do not know how to have jdb leave the WordUniverseTest class and step inside WordUniverse while obj is being constructed. How do I do this?
You can put a regular breakpoint there stop at and then when you are actually on the line (call list to verify), you can call step into.
As long as all your classes are known to jdb, it is going to work, I tested it.
I found the answer, and although Gergely Bacso didn't give the full answer, he did lead me to find the full answer.
jdb uses a different procedure for stepping into methods versus stepping into constructors. To step into a method, you have to do what Gergely Basco said, which is set a breakpoint at where the method is called and then step into. But for stepping into a constructor you must say stop in ClassName.<init> (with brackets). Saying that command will take you inside of the constructor.
Related
I have a Java application and basically I want to know all the methods that are called in the background when I do something in the GUI. I know you can view the Call Hierarchy by selecting a method but that's while the code isn't running. I want to view every single method called in every class when I select something for example so I can figure out which methods/classes/packages are responsible for this functionality. I also don't want to have to set a breakpoint at the start of every method as there are far too many methods/classes/packages for that to be feasible. Bear in mind that I don't even know the first method called for some of the operations, if I knew that, it'd be easy to figure out what's going on.
Is there a way to do this or am I ahead of my time?
I think you could use the debug mode to see all methods called
Run DEBUG in your IDE, your each step in application will move you to the right place in the code, during your program you can see each variable value.
Also you can follow each code line which your code is doing.
http://www.vogella.com/tutorials/EclipseDebugging/article.html
Regards!
I have been using premain() with addTransformer(). Since, it gives javassist.ClassNotFound exceptions for certain classes when i run the agent with a server, i thought to try the agentMain() with redefineClasses(). I went through many links, but so far i am unable to find a piece of code that gives me clear idea on how to set up a simple java agent using these two methods. Some help would be really appreciated.
Can we use redefineClasses() with premain()? (When we use redefineClasses() do we still need the transform method?)
I am trying to instrument set of methods of set of classes, where i know the fully qualified name of those classes as com.test.Foo. I wanted to instrument them without going through the entire set of classes loaded onto JVM. I have been reading those documents back and forth, but still i am unable to get a clear idea on how to use that redefineClasses method?
You can call redefineClasses from anywhere, also from a premain method which is nothing but an extension to a normal Java program run by the same JVM process previous to a main method.
A trivial example for running a redefinition is:
instrumentation.redefineClasses(new ClassDefinition(Foo.class, new byte[] {...}));
This way, Foo is set to be represented by the byte array that must contain a valid class file for Foo where all signatures of fields and methods are the same as by the loaded Foo.class. You can use a tool like ASM for instrumenting the class.
If you really only want to instrument Foo, then this might just be the way to go instead of using a ClassFileTransformer.
I just have a simple question, consider the following method
public void do_something(long arg){
//some work
}
and in eclipse, I added a break point for the above method and run the program, everything is fine, but I cannot find out the stack of current point?! for example
call do_something
push id
call previous_method
call xyz
pop z
call useZ
push z
I mean this method is called by 10 different methods and different stack, how would I find out the full stack of the thread(including methods) with eclipse?! should I change some default property or what?!
To put an image, I repeat my comment as an answer.
In the Debug View you can find the call stack and in the Variables View you can find the actual parameters and values of the local variables:
To get the actual parameters and values of local variables of an other method in the call stack just click in the Debug View on a method above the current method.
This isn't working for a multi-threaded application. You can only see the call stack for the current thread where the method is running in it. Look at:
In the method foo a thread is created by creating a timer. If the jvm suspend on bar, it only sees the call stack of TimerTask.run -> bar but not main -> foo -> run -> bar.
What you've described isn't a stack.
It's a history.
Eclipse isn't designed to give you a history. However, there are other tools that can show you the history, such as Chronon. However, that might be too expensive for you! It also might use too much memory if your application is very complex.
The simplest way to get a history, however, is to put System.out.println("some message") in lots of places.
It can be inconvenient to use System.out.println everywhere, so a couple of other ideas have been developed to improve on this:
Logging frameworks handle common tasks such as printing the time when something happened, rotating big log files etc.
Aspect-oriented programming allows you to inject logging in lots of places at once.
I am working in Eclipse with a program that someone else wrote, There is a certain section where I cannot figure out the procedure of method calls. It seems like methods that modify a class are being called from nowhere at all. Is there a way to see the order that methods are called in eclipse? Like as a debugging feature. Or would I manually have to go add println's to thousands of methods?
One possible way is to set a breakpoint in the method being called "from nowhere", and then inspect the call stack to see from where the invocation came.
The screenshot below shows the call stack in the top-left corner of the IDE.
You can right click the method name, and select Open Call Hierarchy. That will givwe a list of places where the method is called from, and where they are called from etc.
Alternatively you can Thread.currentThread().getStackTrace()
That returns an array of StackTraceElements that represent the current stack trace of a program. You can iterate and print as if it were an exception stack trace, to see where the method was actually called from.
In Eclipse, I would like to set a breakpoint on a Java default constructor. I can't simply double click to the left of any line of code since default constructors have no source code - they are implicitly generated by the Java compiler.
I'd like to be able to set such a breakpoint without modifying the existing code.
If the code where you want to set a breakpoint in, is on the build path and not in your project itself, then if you open the Outline view, you'll see that the default constructor is present there, and you can right-click on it and choose Toggle Method Breakpoint.
Note that sometimes the default constructor is filtered out of the Outline view. In that case it can be included by changing the filter settings. This is done by going to Outline view menu → Filters... → and unchecking Synthetic members.
This is in Eclipse Indigo, I don't know how long this functionality has been around.
If you really need it, set a method breakpoint in one of the other methods of the class, select the breakpoint (Breakpoints view) and export it. Edit this file so the breakpoint points to the standard constructor. At least the following attrib's must be changed (Galileo):
org.eclipse.jdt.debug.ui.JAVA_ELEMENT_HANDLE_ID
org.eclipse.jdt.debug.core.methodName - value="<init>"
org.eclipse.jdt.debug.core.methodSignature - value="()V"
message - no idea if that is really needed
probably easier to also export a constructor breakpoint from an other class to see the correct values. Now import the changed file and you should have your constructor breakpoint.
It's a hack, but worked for me...
I'd like to make a small improvement to the answer given by rsp, making it a bit easier, but I can't post comments yet.
If you create the default constructor (e.g. by pressing ctrl+alt+s and then c), place the breakPoint in the call to this constructor and then press ctrl+z to undo the creation of the default constructor you'll still have the breakpoint with no changes in the code.
Hope it helps
Solution 1: member initializers
If you have any member variables with initializers, then you can put a breakpoint on them. For example:
class MyClass {
private int i = 0; // this line can have a breakpoint in Eclipse
}
Solution 2: class load breakpoints
If you can get by with only hitting this breakpoint once, then you can use a class load breakpoint:
You can set a Class Load Breakpoint,
which will stop when the class is
being lodaed [sic]. Right-click on a class
in the Package Explorer, Project
Explorer, or Types view and choose
"Toggle class load breakpoint"
As the name implies, this breakpoint will be hit when the class is first loaded, so it will only fire once (assuming you only have a single classloader). But depending on your needs, it might be good enough.
you can do the following:
public class MyClass {
public MyClass() {
super();
}
}
And then put the break point on that. However, what are you hoping to accomplish by this?
How about creating a public no-argument constructor and setting a breakpoint on that? If that won't help, could you elaborate why not?
You can always create your own no-argument constructor and put the breakpoint there. More to the point, though, why do you want a breakpoint there? It will simply chain to the no-argument super(). If that has code you care about, put the breakpoint inside that constructor.
Your best bet is probably using an aspect based framework to inject the functionality you need in the classes.
I thought Eclipse provided a default constructor breakpoint, but alas only the class loaded breakpoint in the outline.
What problem do you need to actually solve?
You could consider the YouDebug framework, in order to script your debug session, including a breakpoint on any specific method of any class.
Breakpoints are event callback handlers that are invoked when a certain event occurs in the target JVM. You can create breakpoints by calling breakpoint methods on the 'vm' object. These methods takes a closure that gets invoked when the event occurs, and they often takes additional arguments to control the nature of the breakpoint.
The following code defines a breakpoint on line 7 of the org.acme.SubStringTest.java (or whichever source file this class is defined in:)
vm.breakpoint("org.acme.SubStringTest",7) {
println "I'm at SubStringTest.java line 7";
}