Read in other languages:English Español 中文
There are many debugger tutorials out there that teach you how to set line breakpoints, log values, or evaluate expressions. While this knowledge alone provides many tools for debugging your application, real-world scenarios can be a bit more complex and require a more advanced approach.
In this article, we will learn how to find codes that cause a UI freeze without much prior design knowledge and fix faulty codes in real time.
If you want to follow, start by cloning this repository: https://github.com/flounder4130/debugger-example
Suppose you have a complex application that crashes when you perform some action. You know how to reproduce the bug, but the difficulty is that you don't know which part of the code is responsible for this functionality.
In our example app, sleep occurs when you clickButton N. However, it is not so easy to find the code responsible for this action:
Let's see how we can use the debugger to find it.
The advantage of method breakpoints over line breakpoints is that they can be used across entire class hierarchies. How is this useful in our case?
If you look at the example project, you will see that all action classes are derived from the Action interface with a single method: perform().
Setting a method breakpoint on this interface method will suspend the application whenever one of the derived methods is called. To set a method breakpoint, click the line that declares the method.
Start the debugger session and clickButton N. The application is suspended in ActionImpl14. Now we know where the code corresponding to this button is located.
Although in this article we are focused on finding the bug, this technique can also save a lot of time when you want to understand how something works in a large codebase.
The approach with method lock points works well, but it is based on the assumption that we know something about the parent interface. What if this assumption is wrong, or we can't use this approach for some other reason?
Well, we can do this even without the breakpoints. ClickButton N, and while the application is locked, go to IntelliJ IDEA. From the main menu, selectRun|Debugging Actions|Pause Program.
The application will suspend, allowing us to examine the current state of the threads in theThreads & Variablestab. This gives us an understanding of what the application is currently doing. Since it is locked, we can identify the locking method and trace it back to the location of the call.
This approach has some advantages over a more traditional thread dump, which we'll cover shortly. For example, it provides information about variables in a convenient way and allows you to control further program execution.
Note: For more tips and tricks withPause Programsee Debug without Breakpoints and Debugger.godMode().
Finally, we can use a thread dump, which is not strictly a debugger feature. It is available regardless of whether you are using the debugger or not.
ClickButton N. While the application is locked, go to IntelliJ IDEA. From the main menu, selectRun|Debugging Actions|Get Thread Dump.
Look at the available threads on the left, and underAWT-EventQueueyou will see what is causing the problem.
The disadvantage of thread dumps is that they only provide a snapshot of the state of the program at the time they were taken. You cannot use thread dumps to explore variables or control program execution.
In our example, we don't need to resort to a thread dump. However, I still wanted to mention this technique as it can be useful in other cases, such as when you are trying to debug an application that was launched without the debug agent.
Regardless of the debugging technique, we arrive at ActionImpl14. In this class, someone intended to do the work in a separate thread, but confused Thread.start() with Thread.run(), which runs the code in the same thread as the calling code.
IntelliJ IDEA's static analyzer even warns us about this at design time:
A method that does heavy work (or heavy sleep in this case) is called on the UI thread and blocks it until the method finishes. That's why we can't do anything in the UI for some time after clicking onButton N.
Now that we've discovered the cause of the bug, let's fix the problem.
We could stop the program, recompile the code and then run it again. However, it is not always convenient to refold the entire application just for the sake of a small change.
Let's do this in a smart way. First, fix the code using the suggested quick-fix:
After the code is ready, clickRun|Debugging Actions|Reload Changed Classes. A message appears, confirming that the new code has reached the VM.
Let's go back to the app and check. ClickingButton Nno longer crashes the app.
Tip: Remember that HotSwap has its limitations. If you are interested in HotSwap's extended capabilities, it might be a good idea to take a look at advanced tools like DCEVM or JRebel.
Using our reasoning and some debugger features, we were able to locate the code that was causing the UI to freeze in our project. We then proceed to fix the code without wasting time on recompilation and redeployment, which can be time-consuming in real-world projects.
I hope you find the techniques described useful. Let me know what you think!
If you are interested in more articles related to debugging and profiling, check out some of my other articles:
The above is the detailed content of Debugging Inactive Applications. For more information, please follow other related articles on the PHP Chinese website!
![[Web front-end] Node.js quick start](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
