I'm debugging a normal Java application, no GUI, just a lot of computations and ~5 calls in the stack for the main thread when the problem occurs. Basically it keeps saying "Collecting data" in the local variable watch.
So instead of going step-by-step I've tried to add a breakpoint immediately after an press "Resume". Now it says "Waiting until last debugger command completes".
Have anyone had this problem before? Is changing the debugger the only way to figure this out?
On IntelliJ (2017.1.4 Community Edition), the following fixed the problem for me:
File->Settings
Type in "toString"
Navigate to Build, Execution, Deployment->Debugger->Data views->Java
Find the "Enable 'toString()' object view:" checkbox
Uncheck the box
Re-run the debugger.
The following fixed it for me on IntelliJ 2018.2.4:
Right click breakpoint
Toggle the setting to suspend "Thread" instead of "All"
This won't be helpful if you actually need to suspend all the threads for debugging, but it got rid of the "Collecting data..." and "Waiting until last debugger command completes" messages for me. The setting also persists for subsequent breakpoints, so you only need to change it once.
I just ran into what looks like the same issue. In my case it was a class (KafkaStream) in the breakpoint stack trace with a "bad" toString method. The toString method blocks and therefore hangs the debugger. I tested the toString method in the main line code and it hung the main thread (i.e. this is not a debugger specific issue).
Here is the stack trace for my thread that hit the breakpoint (on a line that was just trying to test a boolean attribute of my class):
Intellij provides a way to work around for my issue. It allows you to override how the debugger renders the class:
If your issue comes back I suggest taking a thread dump (inside or outside of the IDE) and see what your thread is doing.
In most cases, it would be because of the watches that you add while debugging.
Clear the watch statements that would result in recursive execution of same statements as in the code.
Always keep the watches clean before debugging.
It happened to me once (on version 2020.3.3) and "Invalidate Caches" and restart solved it.
The fix that worked for me was to remove method breakpoints. That made it superfast.
Related
I am working on understanding a project which was already created by someone else. It did not followed a proper coding method (no comments and so on). I'm finding it difficult to find where a method is used during the use of the app .So ideally I want to track how each method is used and when it's called while manipulating the applciation . I've already searched the problem here and nothing worked for me. So can anyone please help me out.
I am using Intellij btw .
Thank you .
You can use the debugger of Intellij, that's a really cool tool and besides your problem, it can be used to find bugs in your code.
The basic and easiest way to use it is:
Add breakpoints on lines where you want the application to stop just before executing that line. You can add as many breakpoints as you want and in as many files you want. To add a breakpoint, just click on the empty space beside the line numbering on the left side of the editor window.
then turn on the debugger from the run menu or Shift + F9.
then use the step over option or F8 to jump to the next breakpoint from the current location.
In your case, you can add a breakpoint in the method for which you wanna test, and then see if the program approaches that particular breakpoint during execution.
You can read the more detailed documentation on debugging from this link: Complete debugging guide: Jetbrains.
Hope this helps to solve your issue.
use Find Usages for the method to see where it is used
use a method call hierarchy to see which methods invoke this method
use method breakpoint to stop in debugger any time the method is invoked
I was working/debugging normally on my Java-Maven project with IntelliJ 2018.2.1, I then click on Intellij to Stop the app to make some modifications to the code and when I start the application again in debug mode, it (the debugger) simply stopped working.
Now, the application takes about +10+20 seconds to start and when the breakpoints are hit, it simply hangs and do nothing else.
I have tried many of the suggestions posted on Internet, but none of those seems to work. I also tried to Invalidate/Restart the IDE, but nothing.
Now, the breakpoints aren't even marked as valid any more, it only shows the red circle without the tick verification check. And it also extended to all projects, so now none of the projects the debugger works and the same symptoms are in all projects.
If anyone have any suggestion on this, would really appreciate it.
Solved the issue. It ended up being that I am using another application (NetLimiter) to limit the traffic in the network and I limited few days ago IntelliJ to consume only 5 kbps at any time and this was the problem. I simply removed the limitation and the debugger starting working again normally at its usual speed.
This is typically caused because there is a process running that it is connected to but you have no way to find it.
The only way to resolve it is to reboot your machine.
Now, the application takes about +10+20 seconds to start and when the
breakpoints are hit, it simply hangs and do nothing else.
By this syptom I can suggest that you have accidentally added some field or method breakpoint. Please check that there are no field or method breakpoints present in Breakpoints window (Ctrl + Shift + F8). If they exist - remove them.
I am currently developing a java application, I am trying to use the builtin debugger in Netbeans. I wanted to know how to trace back in the debugger.
Assuming I am executing the instructions line by line, if the program is currently executing 105th line of code and if i would want the program to go back and execute the 103rd line of code, how do i do it? Is this even possible ?
Please read the below link. There is a concept of Pop Topmost Call which might help you.
http://wiki.netbeans.org/FaqDebugBackup
You can do that by setting a break point on 103 line. Then go the call trace and then on the call before to the current right click and do drop to frame. It will re execute that part. Then it will hit you break point on line 103.
I suggest you don't dot it multiple times in the same run. the state of the system becomes unstable for the run by doing this over and over again.
Ive been debugging a project in eclipse. I inserted a breakpoint on a while statement. All was working fine, I was monitoring the variable increments. I tried to change the test class, but forgot I was still running the program, a message popped up and asked a question (I can't remember the exact phrasing) and I clicked terminate. But now when I run the debugger, it runs through the program and gives me the following
<terminated, exit value: 0>
But it doesn't allow me to step through the program. I tried "skip all breakpoints" but that isn't the answer.. It has something to do with the pop up message I'm pretty sure.
Many Thanks for your help
Probably the debugger skips all breakpoints.
Hit the search button in the top right corner
Type skip all breakpoints
Click the result.
Debugger shall be working from now on.
I had the same issue earlier, I have found the answer on youtube :)
Is there a way how to stop debugging when program hits the breakpoint (i.e. I don't want to execute the code after it) without stopping entire application server (I am programming apps in Java, server is JBoss)?
I know only one way how to stop debug - red button with title Terminate which shuts down the server. So is there anything else?
While debugging, context menu offers you to force a return. This instantly leaves the method and will take you back to the caller. One can also use Alt+Shift+F.
If you mean "I do not want the code after my breakpoint to execute", then you could use a conditional breakpoint to execute a return from that method.
(Note that you can execute any code you like in a conditional breakpoint. It does not have to be just a condition.)
You can hit the disconnect button. See the attached image. This will continue execution and stopping debugging without stopping the server.