I am using IntelliJ IDEA 12.1.6 on (64-bit) Windows 7 Enterprise (I've also seen this same problem with IDEA 11, though not as often). I am running it under Java 7 (1.7.45).
When I run a program in the IDE, under the debugger (local debugging), everything is fine until I hit a breakpoint (these are plain old on-a-specific-line breakpoints, not method breakpoints or exception breakpoints). Once the breakpoint is hit, virtually all the time (though not always) my entire machine slows to a near halt. All keyboard operations (not just in IDEA) slow way down (they eventually do get processed so the events are buffered, not lost). Same for window operations (drag, minimize, raise, lower). Once the program resumes from the breakpoint everything goes completely back to normal until the next time a breakpoint is hit.
This is obviously really annoying as it makes debugging essentially impossible.
I've had Task Manager up and don't see anything strange. The CPU is not pegged, memory isn't maxed out, etc. My hard drive light isn't on.
Any ideas on what's going on and (more importantly) how to fix it?
It's hard to say what the problem is, but here are some things that might help:
Invalidate caches as described here--though be aware of the consequences.
Make sure you have only enabled those plugins you are actually using or likely to use.
Try to find if all breakpoints have the same problem or if, for example, you only have issues with Java breakpoints but not JavaScript ones. If that happens, it could give you a clue.
Well, it looks like my specific problem is IE-related.
The program I am debugging is the server-side of a webapp. (Sadly it is IE-only due to some weird stuff in the Ajax it is using -- I'm not responsible for that).
I have been setting my breakpoints, running the server under the debugger, and then doing stuff with the webapp in IE, which ultimately causes breakpoints to be hit. When a breakpoint is hit and I am single-stepping, everything remains OK if I do not use the keyboard at all. If I click on the various single-step icons or select the single-step actions via mouse from IDEA's "Run" menu everything keeps working. But the moment I use F8 to single-step, or hit a key in any other problem (like in a mail program) the freeze happens.
It finally occurred to me (shame on me) to run IE on another computer while running the server in the IDEA debugger on my main computer. When I do that, everything is fine and I can use the keyboard in any application, as much as I want to, and the freeze does not happen.
So the problem seems to be IE causing weirdness when it has sent a request and is waiting for a response from the server. Still, there does seem to be some interaction with IDEA because when I run IE on a separate computer and hit a breakpoint on my computer, I can use the keyboard all I want on the computer where I am running IE without any problems at all.
Related
I'm using IntelliJ IDE (2021.2.3 community) in a java project and I am not able to utilize the debug because whenever I run and it hits a breakpoint it slows my mouse and keyboard, mainly the mouse and it becomes impossible to do anything other than struggle to end the process. That's very weird, I looked into the process manager during the issue and my system looked ok on cpu and memory
Sometimes debugging our purely local desktop application in IDEA 2021.2.4 with Java 11 becomes incredible slow, especially Step Over (F8) or (to a less extend) Step Into (F7). But sometimes even pressing Resume (F9) after having hit some breakpoints is extremely slow while the CPU fan runs at full power (what takes 1s to start normally takes multiple minutes). Stopping usually halts in JDK code, e.g. class loading. I've already verified the breakpoints, but there are just a handful of normal Java Line breakpoints without any conditions. Especially when pressing Resuming other things mentioned in the IDEA FAQ like toString evaluation or Java Type Renderers should not matter, isn't it? Even pausing, disabling all breakpoints, resuming makes no difference.
Any idea how to determine what causes the CPU to heat?
When I use remote debugger in IntelliJ to debug a Java application on server, it stops on breakpoints successfully but when I try to evaluate any expressions or variables it hangs and shows nothing (usually with "collecting data" message). From that point I can't even continue stepping through code anymore. I have to click resume so it at least runs, but it will never stop at other breakpoints too until I restart the debug session and usually even the Java application being debugged.
I can step through the code after stopping on breakpoint, also I see the variables in the debugger panel, it only starts to behave weirdly when I try to evaluate an expression or add a watcher. Then it stops working and restart of the debugger and the app is needed.
Did anybody experience something similar? Is it IntelliJ or server problem?
(sorry this is so vaguely described, but I have no idea what to share or what the problem might be)
Expression evaluation during remote debug need more data to be sync then the other operations ( breakpoints add/remove, step managements ecc ).
So this kind of issue should be just related to:
a slow connection
an huge complexity and amount of data involved into the operation to execute in the remote server
I've got an applet which does something which gets Windows 7 to freeze completely, the mouse pointer no longer responds, ctrl-alt-del no longer works etc.
When I open the task manager, it doesn't show any significant CPU load or excessive usage of memory.
The freeze sometimes happens when debugging on Eclipse as well, but not always.
I'm not quite sure where I should set breakpoints yet since it's a pretty big GUI application.
Could this be a bug in the JVM? Isn't it supposed to be impossible for an applet to do something like this?
Edit: To answer my own question, I found the bug in Eclipse, and it seems that the call to Toolkit.getDefaultToolkit().getSystemClipboard().getContents(null) gets the whole system to freeze, which is pretty surprising since the Excel file is only 1 MB. Maybe the clipboard isn't really designed for situations like this.
Use jStack to generate a Thread Dump. That way you will know what the code is doing. To use it just:
C:\your_java_bin_folder> jstack -l <process-id>
You can get the process id from the Task Manager. jStack is part of the jdk (as far as I know since 1.5).
I'm trying to get to the bottom of a problem with our Java applet based program. It quite regularly seizes up with an unresponsive GUI (or a white screen). This of course only happens when deployed at a customer site :-(. They are running a version of the Sun JVM in 1.5 series (not sure the exact release).
We have a theory that it's to do with the applet running out of heap space - does that sound plausible? The other thing that I have set up on my machine is disabling direct draw, but that was mainly to avoid weird artefacts on other applications.
They are seeing the problem on Citrix and on regular PCs, but obviously there is a limit to what the users on Citrix can do.
Any suggestions?
Running out of heap space should cause an OutOfMemoryError to be thrown. This case sounds like a typical deadlock. To find where that is you want a stack dump of all the threads. IIRC< you can do it through the console, or from IIRC 1.6 the JDK includes jps and jstack.
First of all ensure the customer uses the latest release of the JVM they are using, and make them enable the Java console inside their browser (this requires some research from you).
Then when it happens again, tell them to look at the console window and cut-paste the contents in a mail to you.
In order to solve the problem, you must first be able to reproduce the problem. You will need an identical system in order to troubleshoot this, making one change at a time while keeping everything else equal to determine the cause(s).
Just to add to this answer (to build the knowledge base as I'm currently looking into this).
There's (at least) 2 distinct white screens related to applets.
Deadlock (as mentioned by Tom) - area will not refresh when you drag a window in front of it, so you get the strange tails left effect.
VM crash - area will become white, Java VM closes (search for hs_err_pid*.log, location dependent on browser)