This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
I'm frequently experiencing debugger lock ups, when performing any of step actions (step over, step in, step out, run to cursor). It is random, so there's no reproducible test case. May happen at one point and next time at another. The cure is to restart the debugger. I used to think this was related to conditional breakpoints, as the last time it happened (several days ago) removing the breakpoints seemed to cure it for a while. But now it's happening again, and there are no enabled breakpoints at all. I'm attaching a thread dump and a screenshot. The screenshot was taken after performing "run to cursor"; the highlighted (green) line is the line, where I pressed F4, so apparently it locks up after getting to the destination.
Created attachment 84378 [details] screenshot
Created attachment 84379 [details] thread dump
Product Version: NetBeans IDE 6.7 (Build 200906241340) Java: 1.6.0_13; Java HotSpot(TM) 64-Bit Server VM 11.3-b02 System: Linux version 2.6.28-13-generic running on amd64; UTF-8; en_US (nb)
This is one of the worst lock up - target VM does not respond and we do not know why. One of the possible cause (which I'm dealing with these days) might be a global Pause action. Can you please let me know if this might be involved in your case? Did you use Pause prior this lock up?
I'm pretty confident that most of the times I reproduced without ever using pause. It seems related to the watch expressions. That's what the thread dumps say, and I was able to somehow get rid of this problem for now by removing some of the watches. I'm not sure, which, though.
It is possible that I did use pause on a single thread in the Debugging window every time it happened. I'm not sure, if it was the case, but can't confirm otherwise, either. In the attached screenshot the other thread is paused.
Do you know if the paused "Thread-0" might hold some lock that would prevent from evaluation that is running in "main" thread to finish? In such case, resume of "Thread-0" should resolve the lock up.
That thread doesn't hold any locks. It's completely unsynchronized. Here's the full source code: new Thread() { { setDaemon(true); } public void run() { while(true) { try { sleep(500); printSolution(); stat(); } catch(InterruptedException ie) { return; } } } }.start();
To clarify, the only possible hazard from the other thread is that it prints to System.out. There was at least one watch expression that called a function that printed something to stdout, as well. Could this be the reason for the lock up? I can see why it could happen, if NB allowed the paused thread to run for a brief period (even though it shouldn't). Then the thread might get suspended again in the middle of I/O, possibly while holding an I/O lock in the native code. Is this kind of scenario possible?
This is possible. When one thread is suspended while it's printing something out, no other thread can print in parallel. But according to the screenshot, "Thread-0" is suspended at Thread.sleep, which should not interfere with other calls. It would be best if you could provide some sample project on which we could reproduce the problem (at least once per several attempts).
I can confirm seeing this without pausing anything. Happens straight away after it starts on a breakpoint. Several step overs, and it's stuck. Tried waiting for several seconds after each step, doesn't help.
I've been able to reproduce the issue after removing the watch expression that printed to stdout, but only once. I can't reproduce it without that watch expression anymore, and I am still able to reproduce it with the watch expression. I can send you the source code, but it should not be made accessible to a 3rd party.
I've got a testcase from kirillkh, working on identification of the problem...
As vsiegler asked me I tried to reproduce the problem on x64 Linux i did not reproduce on any of these two builds: Product Version: NetBeans IDE 6.8 Beta (Build 200910020947) Java: 1.6.0_16; Java HotSpot(TM) 64-Bit Server VM 14.2-b01 Product Version: NetBeans IDE 6.7 (Build 200906241340) Java: 1.6.0_16; Java HotSpot(TM) 64-Bit Server VM 14.2-b01 i even tried to hold F8 button a while and IDE never got locked/frozen
Tried to reproduce on the following (jdk the same as kirillkh used): Product Version: NetBeans IDE 6.7 (Build 200906241340) Java: 1.6.0_13; Java HotSpot(TM) 64-Bit Server VM 11.3-b02 System: Linux version 2.6.31-11-generic running on amd64; UTF-8; en_US (nb) Product Version: NetBeans IDE 6.7.1 (Build 200907230233) Java: 1.6.0_13; Java HotSpot(TM) 64-Bit Server VM 11.3-b02 System: Linux version 2.6.31-11-generic running on amd64; UTF-8; en_US (nb) Product Version: NetBeans IDE Dev (Build 200910160201) Java: 1.6.0_13; Java HotSpot(TM) 64-Bit Server VM 11.3-b02 System: Linux version 2.6.31-11-generic running on amd64; UTF-8; en_US (nb) The same also with: Java: 1.6.0_16; Java HotSpot(TM) 64-Bit Server VM 14.2-b01 I am unable to reproduce this no matter how hard I try - stepping into, over, out, adding various watches.
Thanks a lot Filipe and Vojto. Kirill, unfortunately I have to close this as works-for-me, since we're not able to reproduce this issue, even with the code that you've provided. Please try the 6.8 M2 or the upcoming beta.
verified in NB 6.9 - closing