I have an object that has a set of methods called on it like:
objectName.method1().method2().method3();
and I want to know which one of those methods is causing the NullPointerException to be thrown. Is there a way to do this in the Eclipse debugger?
If you want to know which specific value was unexpectedly null (e.g objectName or return value from method1() or method2()), then I recommend splitting this logic into multiple lines. Then, you'll be able to set specific breakpoints in the debugger and step to the exact failing line of code.
This has benefits when running in production too. If it happens after you deploy or in a live customer environment, then you'll get a more specific line number in the stack trace that points to the exact line of code with the problem.
This can be done with some careful stepping in Eclipse debugger. Put a breakpoint on the line you are describing. If you have local variables available in bytecode, then you will immediately know it the first call causes problems by looking at a value of objectName. If it is null, you know that it is the first call.
If not, step into the method (F5). This will bring you to the implementation of first method. Then you can immediately return from it by stepping out (step return - F7). You should be back at the orignal line with debugger ready to step through the next method. You continue by stepping into again (F5). That should take you to the implementation of the next method. If you arrived there, then there is still no exception. Step return (F7) again.
Continue until you get to some exception handler instead of the method you wanted to step into. This is the one you are after, or perhaps the one before it, because that one returned null.
You can also play with "Run to line" function (default Ctrl + R) to do that a bit more easily.
Related
In C# I can write:
if(Debugger.IsAttached)
Debugger.Break();
This has no effect when the program is not being debugged. When a debugger is attached, it behaves like a breakpoint that can never be turned off. How can I achieve similar effect on Android?
Or maybe I should not focus on breakpoints at all. What I really want is to have no consequence in regular use (a generic error message will be shown to the user), but have the source of error become obvious the moment a dev will start looking at it. I've tried assert, but it's a sub-project that's compiled to release flavor most of the time and I can't rely on someone remembering to switch it to debug.
I think that Debug.isDebuggerConnected() is what you are looking for. This will return true only if the app is started with debugger attached and false otherwise, no matter of build type or flavor. Unfortunately, I don't think that you can stop the execution programatically, but with the above instruction you should be able to display an error message or throw an exception. Personally, I'm thinking to something like this:
if (Debug.isDebuggerConnected()) {
// throw an exception for the developer with a detailed message
} else {
// show the general error message to the user with a dialog/toast
}
I was also hoping that this could be done, but I've not found any reasonable way to programmatically cause the debugger to breakpoint. What I've done to get around this problem is to create a breakpoint class with a method call "br". When I'm debugging, I'll set a breakpoint in the "br" method. After that, whenever my code calls the "br" method, the debugger stops. I then step out of that method and then inspect the state of the program where the "br" method was called. Hope that helps!
If i clear understand you - try this snippet of code:
if (BuildConfig.DEBUG) {
// Your, developers behavior
}
else {
// release behavior
}
Whenever adding a breakpoint to the line of a method declaration (in Intellij IDEA or Android Studio), a popup appears:
Method breakpoints may dramatically slow down debugging
Why would it dramatically slow down debugging, is my question? What is different about putting the breakpoint on the first line of the function?
Thanks!
I looked around a little, and saw this post in the Intellij Documetation:
Method Breakpoint
Method breakpoints act in response to the program entering or exiting a particular method. They let you target your debugging sessions by method you wish to investigate, rather than by line number. Method breakpoints let you follow the program flow at the method level as well as check entry and exit conditions. Note that using method breakpoints can slow down the application you are debugging.
I guess it stops the program right before it enters the method, so that you can evaluate the parameters and such before entering the method.
The reason it dramatically slows down is (This is what I can gather, because that is all I could find on method breakpoints in Intellij's documentation) that it has to:
let you follow the program flow at the method level as well as check entry and exit conditions
and I suppose that would take a lot longer than just halting the program's execution
My understanding is that the code must be run interpretively (instead of using JIT to pre-compile?) when the breakpoint is set on method entry.
If you set the breakpoint on the first line of the method instead, I suspect a line number index into the code can be used to simply swap a break opcode for the original opcode, so the app runs full speed. (which still seems pretty slow to me when debugging ;)
There is a simple explanation from the IntelliJ Team: "Method breakpoints will slow down debugger a lot because of the JVM design, they are expensive to evaluate"
https://intellij-support.jetbrains.com/hc/en-us/articles/206544799-Java-slow-performance-or-hangups-when-starting-debugger-and-stepping
Lets say I have a class that initiates two threads Thread_A and Thread_B, each doing some calculations and ocassionally using a subroutine of my the class. (don't worry about data sharing, lets say it's a log line or imagine the subroutine is a method in a Java library) I want to know if there is a way of conditioning a breakpoint inside this subroutine to the subroutine having been called from say thread_A, but not B, or say a certain breakpoint having been hit prior to this breakpoint.
Obviously I can always go tho the frames tab in the debug window and see the caller thread, but it is tedious. It might be the case that thread_A accesses the subroutine much less often than thread_B. I don't want to have to see all the breakpoints which are initiated by Thread_B.
The way I currently do it, is setting up global flag variables and manipulating them just before calling the routine. I then have my breakpoint's condition depened on the flag variable. However that is probably not very thread-safe and not very clean.
What is the correct way of doing this? Out of curisoity, is there any other IDE for any other language that does this?
is the code that spwaned the threads your's ?
if so you could set unique names on the threads and use those names to
distinguish your threads when using breakpoint conditions.
e.g.
//spwaning the thread
Thread threadA=...
threadA.setName("thread-A");
// IntelliJ
Condition : Thread.currentThread().getName().equals("thread-A")
By way of some library, I find myself calling this function twice concurrently on a single instance (using the implementation returned by Executors.newSingleThreadScheduledExecutor). The Runnable passed to the second call seems not to execute, neither immediately nor on the next scheduled slot, and no exception is raised. If I serialize the two calls (did this very crudely and unintentionally by putting a breakpoint before the second caller's scheduling call), then the second runnable is executed with no issue.
I'm new to this interface, but it doesn't seem like these scheduling functions are designed to be reentrant. But I can't find anything in the various documentation describing what should happen here.
Well, small test case doesn't reproduce the problem, so I have no reason to believe the function isn't reentrant. What actually fixed the problem was to remove all this from request time to server start. There were some other signs, like the breakpoint temporary fix I mentioned in the OP, that point to some awful timing issue, somewhere in my stack.
I am getting java.util.ConcurrentModificationException but I need to figure out which class gives me this exception. The code has numerous classes and packages and it is difficult to figure out where the error comes. The exception shows the problem of ArrayList. It doesn't catch exeption when I use exception handling in suspected areas.
Any way out?
If you're using a modern IDE, eclipse for example, then you can run the application in debug mode and set a breakpoint on any Exception. With the effect: the application will stop each time the exception is thrown (in the entire JVM) and you get a stack trace.
That makes it quite easy to identify the caller (and the actual thread, if it is a concurrency issue)
playn.java.JavaGroupLayer.paint(JavaGroupLayer.java:96)
That's the bad guy. It's the paint method your JavaGroupLayer class. It probably has a for loop that iterates through an array list and at one point it detects, that the list has been modified.
Do you use threads in your swing application? In that case, double check that they do not modify the layout.
Usually start at the top of stack trace, and the first class that you wrote/recognize as yours should be your entry point. Afterwards, you probably make calls in other classes/methods, so you can follow the stacktrace and hence the offending code.
Additionally : What you are probably doing (I have done that in the past myself) is trying to modify a collection, while iterating over it. This is what concurrent modification means. Try to see where you are doing that and should be it.
Go through the stack trace from the top to bottom and the first class that belongs to your source code is the one that has received the exception from an ArrayList trying to do something illegal with it. Then check which threads are accessing that instance of an ArrayList in the same time and protect it with synchronized methods or synchronized blocks.
A common mistake is to discard the exception, only read the message or toString the exception. If you print the stack trace, you will be able to see exactly where (the class, the method and the line) of each level of the stack.
Exception in thread "AWT-EventQueue-0" java.util.ConcurrentModificationException
at java.util.ArrayList$Itr.checkForComodification(ArrayList.java:782)
at java.util.ArrayList$Itr.next(ArrayList.java:754)
at playn.java.JavaGroupLayer.paint(JavaGroupLayer.java:96)
at playn.java.JavaPlatform$1.paint(JavaPlatform.java:222)
at javax.swing.JComponent.paintToOffscreen(JComponent.java:5138)
at javax.swing.RepaintManager$PaintManager.paintDoubleBuffered(RepaintManager.java:1454)
at javax.swing.RepaintManager$PaintManager.paint(RepaintManager.java:1385)
In your IDE, you should be able to click on each line to see the code involved.
Given this is in a package, it is more likely that the problem is that you have used the library incorrectly. It appears that plyn is not mult-thread safe and you have a attempted to change a data structure in another thread instead of using the swap AWT thread.
Identify the list, then either change the iteration to use list iteration (for i=0; i < list.size(); i++) rather than Iterator iteration (for x:list)
Or you can make a shallow copy of the list and iterate that.