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.
Related
I was assigned a task to create a custom stacktrace like output to a log file for some specified functions, but instead of just using the class and method names I would also have to output the parameters and their values.
This is supposed to be a separate jar that could run on any java project, after.
I don't even know if such thing is possible, let alone where to start.
Any help would be appreciated.
EDIT: there is other library that does that by using native VM api: https://github.com/cretz/stackparam it also modifies Throwable class to always print that modified stacktrace.
The only possible way I can think of is using agents and instrumentalization, but agent needs to be added to startup command line.
Then I would register transformer to transform every class (remember that some basic java classes might be already loaded) using ASM library and add code to beginning of every method invocation to manually track each method class and pass it to my library that would track them:
// note that parameters names might not exist in runtime if code was compiled without a flag to include them.
public void doSomething(String name, int something) {
MyLib.enterMethod(ThisClass.class, new MethodSignature(void.class, String.class, int.class), new Argument("name", name), new Argument("something", something));
try {
// original code
} finally { // so we don't need to care about return in the middle of original code or exceptions
MyLib.exitMethod();
}
}
enterMethod would add invocation frame to some queue and exitMethod would remove last added frame. Note that you should have separate queue for each thread, use some Map<Thread, MyFrame> or ThreadLocal it might be good idea to use some weak references for threads.
And then you could use frames from that queue to create own stacktrace.
But doing something like that might decrease performance a lot - not even just because cost of this code, but adding that to every setter/getter might cause that methods to never be inlined and affect performance even more.
So it is possible but I really don't recommend doing something like that.
Also some other transformers added by other libraries might affect results, it might be good idea to also compare your stacktrace with original stacktrace to find any missing methods that you didn't transform - like native ones, and add them to your stacktrace but without that additional data.
If you really need to support native methods too - then you can create more advanced transformer that would add enterMethod/exitMethod before and after call to native method.
Also if this is only for debugging you could use debugging API so it would only work as a debugger.
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 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.
i need to know which methods were invoked one by one in code. Simple step-by-step debugging doesn't help (need too much time). How can i do this? It would be really great do this without changes of code and saving result in file.
Since it seems that maybe you don't want to check the stack tree, just the order, you could check out BTrace or Adding logging with Java agent.
Before your program finishes, you could Thread.currentThread().getStackTrace(); and then print each of those elements. A stack trace shows you the order of execution in your thread.
Sounds like a cross-cutting concern, especially when you talk about not changing existing code.
AspectJ is available to do this work for you using pointcuts.
http://www.eclipse.org/aspectj/doc/released/progguide/starting-aspectj.html
Do you mean you want to log every method call that occurs in your program? If so, have a look at AspectJ - there's an example here which logs particular methods, but you can easily adapt it to cover all methods.
What about when you catch a Exception you can try to use printStackTrace() function to dump out what has been invoked.
try{
//Your code
}
catch(Exception e){
e.printStackTrace();
}
Run your code in debug mode, you'll be able to set breakpoints to pause the execution, proceed line by line, inspect variables, etc.. Basically all the IDEs have debug mode.
I am trying to access a global event created by native code in my java client. I am using JNA for this purpose to call OpenEvent method of kernel32.dll. But the method always returns NULL and GetLastError returns 2, which is File not found.
So I was wondering if JVM can see these global events and if so is there any other approach I can use?
--
Vinzy
How do you call your openEvent?
I suppose it's something like this
int result = kernel32.OpenEvent( 10000, false, "Global\\nameOfEvent" ); //request for deletion
with the only difference you may be using objects as arguments, which, I suppose, is a matter of preference.
Maybe if you provide the code for the call we might be able to help you. Another thing to be asked is if you call CreateEvent in your native code somewhere. If you dig into the Windows API, you will notice that:
"The function succeeds only if some
process has already created the event
by using the CreateEvent function."
source : http://msdn.microsoft.com/en-us/library/ms684305(v=vs.85).aspx
Which in your situation mean you will be in a lot trouble if you were not the one creating the event. There is a way of obtaining a handle to an event you did not create but it's a bit more complicated and let's start by you providing a bit more information.
Cheers.
To sum it up:
If you don't call CreateEvent anywhere in your code you will have trouble when calling OpenEvent. To escape this problem you would basically have to find which process/thread holds the lock to the event and make it give it to your thread (the jvm's).
If you do call CreateEvent in your code then you should not have any problems obtaining a reference to your event and the culprit is somewhere else.
In any case, a bit more code would be nice.