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
  • Created by   Ivan Petrov
    3 years ago (07 Nov 2008 16:13)
  • Updated by   Ivan Petrov
    3 years ago (10 Nov 2008 18:42)
  • Jira: IDEA-20497
    (history, comments)
 
IDEA-20497 Debugger does not suspend the other thread
0
Issue is visible to: All Users
  The issue is visible to the selected user group only
I am posting my comment from IDEA-42472 as a new issue, since it is not resolved and is slightly different from the initial subject on IDEA-42472

It seems, that there is no progress on that.
At least try to fix it in the new 8 version - this is serious and important drawback

I'm trying to help, here is a simple example (attached also)
ThreadDemo.java

ThreadDemo.java
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();
        }
    }

}


I start debugging, the first breakpoint is hit - for cycle, then I'm stepping over with F8, several times, the new threads are started and they print in the console, but the execution never stops on the second breakpoint in the run method?!

Breakpoint suspend policy is 'All', toString() and Disable JIT are turned off, Alternate view for Collections too. I'm attaching screen shot of the settings too.

I tested it with Sun's JDK version 1.4.2_17, 1.5.0_14 and 1.6.0_10
Idea version 7.0.4 #7941

It was OK with my previous versions 5.0.x and 6.0.5 (just tested it again with 6.0.5)

Environment: MS Windows XP SP3, Sun's JDK version 1.4.2_17, 1.5.0_14 and 1.6.0_10

Issue was resolved
Comments (3)
 
History
 
Linked Issues (?)
 
Eugene Zhuravlev
  Eugene Zhuravlev
07 Nov 2008 18:47
3 years ago
Please find my explanation in the IDEA-42472 discussion thread for that:

"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."
Ivan Petrov
  Ivan Petrov
10 Nov 2008 18:02
3 years ago
I understand you point, but it's not ok for me.
Is there any chance to return the 'Suspend all threads' button in the debbuger window, which worked perfectly in version 6?
Eugene Zhuravlev
  Eugene Zhuravlev
10 Nov 2008 18:42
3 years ago
No. "Suspend all threads while stepping" button has nothing to do with the functionality you are describing - it was introduced as a workaround to overcome very slow thread suspension/resumption on early versions of jdk 1.4.

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.