I have the following problem, we might even call it a classic one:
public void myMethod(Map<Object, Object> parameter){
someOtherObject.method(parameter);
.
.
.
someOtherThirdPartyObject.method(parameter);
}
And suddenly, in the end some method touched the input parameter Map, and I don't know where and how. Now, I know it would be desirable to make the parameter immutable, but it is not and that is the root of the problem. For instance, the methods inside myMethod are intended to perform some validations, but they do some more as well, which is wrong by design.
So, the question is how to create a breakpoint in this method where the execution pauses if an attribute of this parameter Map changes? It might be a good idea to put a conditional breakpoint after each method call, but if you have 20-odd methods, it's rather painful.
How can I debug when this input parameter is changing?
What you want appears to be called a "watchpoint". I actually didn't know this functionality existed and I used to work on the Eclipse Project!
http://help.eclipse.org/indigo/index.jsp?topic=%2Forg.eclipse.cdt.doc.user%2Ftasks%2Fcdt_t_add_watch.htm
It looks like you'll have to figure out what fields are being editted and then set a "Write" watchpoint using the help document above.
Additionally, Eclipse highlights variables which are modified, so if you step over your method calls one by one you will be able to see which one is modifying the value (and which field is being modified) because it will be highlighted (bright yellow, by default) in the "variables" tab in the "debug" perspective. Once you know which method if modifying the data you can run debug again, but this time debug the method that changes the value and just keep repeating until you find the problem.
This is a classic problem solving scenario where you start with a very large search space and systematically and methodologically narrow it down until the search space is small enough for you to locate the problem.
If you're trying to locate a spot where your map is being modified incorrectly, you might want to first start at the higher levels of the myMethod. Put breakpoints around the methods called inside the myMethod method. At each breakpoint, look at the contents of the Map. Eclipse has a variable watch panel where you can see the contents of every variable at a specific moment in time.
When you hit the breakpoint where you notice something is wrong. Stop. You now know to dig into someOtherObject.method(parameter); assuming the data was changed at it's breakpoint.
Now, someotherObject.method will likely have other methods inside it. Put your breakpoints inside this method around all of it's function calls and repeat the process. Continue repeating until there are no more methods left. Eventually, you will narrow down the problem and have the answer.
Unfortunately, there is no magic "fix my code" button for these types of problems. It just takes good, old fashioned Sherlock Holmes style investigative skills and reasoning to eliminate areas of the code that you know aren't the problem until you're left with a smaller section that allows you to get at the root cause.
If no code modification is allowed, you can
use the watchpoints method described by acattle to watch changes at this specific map instance or
have breakpoints in the Map methods modifying its state (if you want to do that for multiple instances). It does not matter that the Map code is binary only, you can still open it using Ctrl-Shift-T (Open Type), select the methods like put(...) or remove(...) in the outline view and add breakpoints using the context menu in the outline view.
Related
There is a possibility to add a watchpoint in the Eclipse, like mentioned e.g. here How to detect when a variable changes value
After invoking the watchpoint, the class which contains watched field is displayed and I am able to see that a setter was called. What I would like to know, is where exactly, in which place in the code, the setter(or constructor) was called.
This existing answer suggests that there is no such feature.
But beyond that, there is a simply workaround: use eclipse to find all usages of the method/ctor that sets the thing you are interested in, and then put break points on each of those.
Alternatively, you could put a test in your code under test, to throw exceptions in certain cases, delivering you a nice stack trace containing the call chain.
I'm using a number of frameworks, boot, hibernate, etc, in our code, including enhancing and generating code. When I call what looks like a simple method of code it will go through CglibAoPProxy and similar methods before to call the method I want. This means if I want to look into the next piece of my code I need to either walk through 5 lays of stack trace for code I presume is functional (and thus don't care to trace it's logic) to get to the next method of code I personally wrote, or add breakpoints and where I want to break, hit run, and then remove the breakpoint after.
What would be nice is if there was an easy way to tell the debugger that I only want to look at my code. If I step into a method implemented by some library just keep running until it hits the next line of code that is part of a library I wrote. Is there an easy way to configure the debugger to do this? to only care about code I personally wrote when stepping into something?
Likewise, when I want to move back up the stack trace, to look at an earlier phase state, it's very difficult. With so many levels of methods from libraries it's hard to find the ones that contain code I personally wrote. Is there a way to highlight only your methods (say methods from the current working set) or something similar in the stack trace?
Step filters may help.
Open Eclipse preferences. For example, on Windows, use the menu item Windows>Preferences.
Navigate to Java>Debug>Step Filtering.
Turn on the checkbox Use Step Filtering.
In the checkbox list titled Defined step filters, turn on checkboxes of package hierarchies you'd like to skip. Use the buttons alongside to add additional filters.
All that said, I hadn't used step filtering until your question led me to look into it. Not yet sure how I personally feel about skipping code while debugging. But that last item in the default filter list -- java.lang.ClassLoader -- looks very helpful.
When debugging in IntelliJ Idea if I put a break point on a method signature it warns me about slow performance. However, what I do instead is just put it on the first executable line of code in the function and it works fine for my purposes.
My understanding is that if I see the function I will for sure see right before the first line of executable code inside the function but IntelliJ disagrees. What differences would I expect to see in with these two different debug methods?
Using method breakpoints creates a need to check every time a method is called to determine whether it needs to be breaked for every method call on the application. They also disable JVM optimizations such as method inlining.
Regardless to say this issue is not IDEA related, might even be applicable for other programming languages.
Don't have IntelliJ IDEA in front of me, but based on documentation, I think with method breakpoints you aren't actually going inside method implementation, but rather step-by-step on method calls. Which is probably the reason for performance impact, since IDEA must walk through caller stack, compared to just walking through lines of code in a single method in case of line breakpoint.
I've come across what seems to be a bug in Eclipse Kepler while debugging. One of my variables is incrementing itself randomly with every step of the debugger, even through steps that do not change the variable at all. Screenshots included below:
The method advanceLine() increments progress by one
The very next step, progress increments twice, before it even reaches the increment
There is another thread that accesses progress, but it does not modify it. These random changes don't seem to affect my program at all, just the debug view. Also, for some reason, the shortcut to Step-Into (F5) doesn't work despite being already bound. Does anybody know what's going on?
Variable progress is a class variable and if it is getting updated ambiguosly, it is possible that another thread is modifying your variable. Please make your variable local.
There is no way eclipse interferes your coding logic unless you explicitly right click on a variable and change its value.
Well.. I figured it out. I removed the variable watch from the Expressions view and added it back in. Lo and behold, it displays normally and my code has not altered at all. I think it was just the view that was acting wonky because like #Vineet says, Eclipse does not modify values in your code unless you tell it to.
In a class with 750+ lines, it is very time consuming to scroll through the code searching a specific method. when you're not the author of the code, wasted time multiplies.
What techniques do you use when you need to quickly jump to a specific method? Remember, it's not your code and you cannot memorize method name. You also cannot jump to a specific line as it's hard to memorize line numbers.
I use two approaches, which are the best I came up to.
I set a breakpoint at some method. Pro: visually appealing, Con: irritating when debugging and mixes with the "real" breakpoints
I set //TODO marker at some method. Pro: easy to navigate via Todo list. Con: mixes with "real" todo tasks and increases possibility to oversee some task
Please advise...
This is one of the things IJ does best.
ctrl-click/ctrl-b: jump to definition from its usage (you should be using this constantly)
Structure View (Alt-7) combined with the structure view button which says "Scroll From Source"
ctrl-shift-left/right: move between previous cursor locations edit location
ctrl-alt-shift-N: find any symbol by name. Even if you dont know that much of the name. You can use wild cards, and camel case, or leave it all lowercase and perform case insensitive search.
Alt-F6 : find usages of element at caret. (Show me where this API is being used)
Bookmarks, they work like your breakpoints and todos, except their intended purpose matches your needs - are all visually different and support quick keyboard navigation.