|
Project
|
IntelliJ IDEA
|
|
Priority
|
Normal |
|
Type
|
Bug |
|
Fix versions
|
No Fix versions |
|
State
|
Won't fix |
|
Assignee
|
Eugene Zhuravlev |
|
Subsystem
|
Debugger |
|
Affected versions
|
No Affected versions |
|
Fixed in build
|
No Fixed in build |
public class ThreadDemo extends Thread
{
private final String name;
public ThreadDemo(String name)
{
super();
this.name = name;
}
public void run()
{
for (int i = 0; i < 10; i++)
{
//breakpoint at the line bellow - we never stop here?!?
System.out.println("Thread [" + name + "] : " + i);
try
{
sleep((long)(Math.random() * 1000));
}
catch (InterruptedException e)
{
e.printStackTrace();
}
}
}
public static void main(String[] args)
{
//breakpoint at the line bellow
for (char c = 'A'; c < 'D'; c++)
{
new ThreadDemo(String.valueOf(c)).start();
}
}
}
"Ivan, while you step (use either stepInto or StepOver commands), there is an implicit thread filter added for the current thread and breakpoints in other threads are ignored. When you do "Resume" (F9), the thread filter is removed and any thread can hit any breakpoint."
Is there any chance to return the 'Suspend all threads' button in the debbuger window, which worked perfectly in version 6?
If your breakpoint's suspend policy is "suspend thread" - only the thread that hit breakpoint will be suspended/resumed while you are stepping. If suspend policy is "all" - all threads will be suspended/resumed. This is what effectively the button did - if the option was off, only current thread was suspended and resumed while you performed stepping. This significantly improved stepping speed. Now the problem is fixed in JDK and thread suspension/resumption policy was made consistent with the the suspend policy of the event (breakpoint) that caused initial thread suspension.