I am debugging an application with lots of threads. My breakpoints are set to suspend the whole VM.
When a thread hits one of the breakpoints, I then want to use Step Over. But this appears to resume the whole VM, until that step completes.
It'd really help if I could step just the single thread that hit the breakpoint.
Is there any way to do this in IntelliJ 11.1 / Java 6? (Hope I'm not missing something obvious...)
This feature was added in IntelliJ 16 (the issue CrazyCoder referenced in his answer was resolved)
More details here:
https://blog.jetbrains.com/idea/2016/02/intellij-idea-16-eap-improves-debugger-and-adds-git-worktree-support/
NetBeans can resume individual threads. While in debug mode, you can resume a thread from the left thread list by pressing a small button shaped like Play (►) near the thread.
Currently there's no such possibility because it may lead to deadlocks. You may vote for IDEA-43728 though.
Related
Back when I was using Eclipse for Android development, it was possible to select a thread and freeze it - so it would not run. This allowed the debugging of one thread without interruptions from other threads.
How can a thread be frozen - prevented from running - in Android Studio. I have found the list of threads but I do not see any controls for freezing a thread.
--------< additional information >----
2 people didn't understand the question, so let me try again.
In Eclipse, when debugging a multi-threaded app, you can suspend and resume threads in the debugger.
In the above image, you see the Debug view, showing a list of threads. Right mouse on one of these threads and in the menu is Resume, Suspend, Terminate. These menu actions apply to the selected thread.
When debugging multi-threaded apps, sometimes it is essential to suspend a thread temporarily.
In Android Studio, I can get a dump of the threads, and selecting each one shows me its stack trace on the right.
But I can not find any way to suspend and resume the thread.
Again this is a critical requirement of a debugger.
Does anyone know how this suspend/resume can be done in Android Studio???
I haven't looked under hood to be sure of this, but I imagine that it is using JVMTI. This "hooks into" the JVM at a lower level than is possible through the APIs in the Java class libraries.
And, before you ask:
I doubt that JVMTI is available on a real Android device. (I don't know if there is an equivalent.)
A Java application using JVMTI to control its own threads would be a really bad idea. Think about the reasons that Thread.stop and friends were deprecated, and multiply by 10.
I have to develop new features and change some extisting ones in a buggy extensive Android application (where any changes may affect completely "unrelated" part of code) and I encountered a bug where application freezes (not responding).
So I figured it is probably a deadlock. But how to debug this? I cannot go step by step since we have many threads running and I dont know where to put a breakpoint...
Is there any way to break in debug and get a line (or part of code) where application is currently running?
Hope its not too chaotic, but I am exhausted from hours of testing...
If you are using eclipse.
You can suspend the debug session from the debug view.
Check the threads currently in action
From the stack trace of threads you can get a fair enough view of the current situation.
For further investigation you can use JConsole to debug the deadlock.
Check here https://kellicker.wordpress.com/2010/05/03/deadlock-debugging-in-eclipse/
cheers,
Saurav
As your app is multi-threaded, the best option may be to make use of debug logs in your code. You may get some clue about the part that is causing deadlock.
I have a problem while debugging in IntelliJ IDEA, it hangs in debug mode on break point in listeners in javafx application. I tried to increase heap space, but it's not help. Maybe someone had such problem too, please, suggest me what to do.
Set this as a VM parameter:
-Dsun.awt.disablegrab=true
It will mess up drag-and-drop, and leave an artifact on your screen while the debugger is paused - but it will let you debug. It happens whenever you block the JavaFX thread.
This can happen for a simple reason: The application has a lock on the desktop, for example a modal dialog or a popup or an open menu. Then it stops in a breakpoint. This notifies the IDE. Now the IDE tries to do something on your desktop but can't since the application still has a lock on the whole desktop -> deadlock.
You can use a tool like Chronon which records the whole program and lets you move back and forth on the timeline.
The last option is logging or poor man's debugger (System.out) instead.
[EDIT]
it's hard to check with System.out which of 20 parameters not equal.
It's actually pretty easy:
System.out.println("check");
if(!a1.equals(b2)) System.out.println(a1+"!="+b1);
Then duplicate the last line. That way, you will only get output when something is actually interesting (and not for the 19 equal parameters). Add some patterns to the output if you can't distinguish aX from aY (i.e. both are true):
if(!a1.equals(b2)) System.out.println("a1:"+a1+"!="+b1);
Is there a tool I can use to see what parts of the code are in which thread (colour code it or something)? I'm mostly concerned about EDT, but writing that isOnEventDispatchThread()-ish command every other line and then keeping track of it's output while the program is running is tedious and time consuming.
The major problem I'd see with this is code that can be called from any thread, such as constructors. You can however use Eclipse's debugger at runtime. Simply run the program in the debugger until a breakpoint or with manual pause then look at the "debug" view that is generally in the upper left. You'll see threads and may select one to jump to its location.
VisualVM is practically the standalone Netbeans Profiler (which is a great tool, by the way).
But what I am missing, is the ability to initialize monitoring settings for a process before it starts.
Usually, in VistualVM, one can open a process and start changing settings only when the process is already running. This is a problem when one should want to profile a shorter-term process.
Sadly, this solution doesn't work: A Java program doesn't starts "fast enough", and gets suspended before it would be recognized by VisualVM as such.
Is it possible to do somehow?
NOTE 1: My current workaround: I added a cmd-line switch to my project: "-W" to wait for an [enter] key press.
NOTE 2: Strange, the Netbeans Profiler still gives much more realistic profiling results. But it has a bug currently, which forces me to recompile the main project the amount of times of linked projects ;) That'll be 12... And I failed to reproduce the bug.