Product Version: NetBeans IDE Dev (Build 201512240002)
Java: 1.8.0_66; Java HotSpot(TM) 64-Bit Server VM 25.66-b17
Runtime: Java(TM) SE Runtime Environment 1.8.0_66-b17
System: Windows 10 version 10.0 running on amd64; Cp1252; en_CA (nb)
User directory: C:\Users\Gili\AppData\Roaming\NetBeans\dev
Cache directory: C:\Users\Gili\AppData\Local\NetBeans\Cache\dev

I have flagged this issue with a P1 because it is a regression and because some applications cannot be debugged using "Suspend: Breakpoint thread" (in applications where the state of one thread causes another thread to do the wrong thing).

Testcase:

public class DebuggerDeadlock {

    public static void main(String[] args) {
        for (int i = 0; i < 100; ++i) {
            new Thread(new Runnable() {
                @Override
                public void run() {
                    new DebuggerDeadlock().run();
                }
            }).start();
        }
    }

    public void run() {
        SomeClass base = new SomeClass();
        base.someMethod();
    }

    public class SomeClass {

        public void someMethod() {
            System.out.println("one");
        }
    }
}

Repro steps:

1. Set a breakpoint on the line "SomeClass base = new SomeClass();"
2. Configure the breakpoint to "Suspend: All threads" and enable "Default for New Breakpoints"
3. Start debugging session (CTRL+F5)
4. With the Debugging tab open on the left, hit F5 (continue) 10 times (we are making sure enough threads are running in the Debugging tab).
5. Now, step over (F8) "SomeClass base = new SomeClass()" and step into (F7) "base.someMethod()"

When running the above steps, I usually get a deadlock in step 5: the thread you were in will read "running" in the Debugging tab but will never enter someMethod().

Other times, I will get a deadlock on step 4 (hitting F5). Other times I get it when stepping over (F8) code in step 5.

This bug is intermittent but occurs very frequently. Please let me know whether you are able to reproduce it on your end.

This bug seems to be specific to "Suspend: All threads". I have not been able to reproduce it for "Suspend: Breakpoint thread".