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.
Created attachment 151895 [details] Constructed code to demonstrate issues Inspired by bug 250175, comment 14, I prepared a small test class and was surprised how easily misbehaved Java code can bring NetBeans to a grinding halt. Debug the file, see comments in the attached source. Should a debugger really depend so much on correct target code? It isn't even possible to write these few lines in NetBeans, the IDE just freezes. Try, for example, to duplicate (copy&paste, then save) a test block (could be related to COS, I didn't evaluate further). System Info: Product Version = NetBeans Platform 8.0.2 (Build 201411181905) (#8230772f5f18) Operating System = Linux version 3.12.36 running on i386 Java; VM; Vendor = 1.8.0_31; Java HotSpot(TM) Client VM 25.31-b07; Oracle Corporation Runtime = Java(TM) SE Runtime Environment 1.8.0_31-b13 Java Home = /opt/java/jdk1.8.0_31/jre System Locale; Encoding = de_DE (nb); UTF-8
Created attachment 151897 [details] Exception thrown shortly after I wanted to see value of "hoverMe" variable in its tooltip
Created attachment 151898 [details] Self profiling snapshot taken during evaluation of the "hoverMe" variable value for tooltip. I have reproduced a slowness but IDE became always responsive after ~8 seconds long UI lock.
When you let the debugger do enough work, you can easily freeze it. This is actually expected. We have discovered a huge memory consumption by Swing JTextArea rendering thanks to your example. This is submited as issue #250307. I'm searching for a workaround...
Are you saying that nobody can reproduce the IDE freeze when trying to save an additional (copy&paste) test case? Then my NetBeans configuration (btw I'm using source and target platform 1.6) is broken, because it happens to me every time I try this. Concerning the debugger: Forgive my ignorance but isn't it possible to monitor the invocation of the toString method and give some visual feedback at least, say by switching to WAIT_CURSOR after 200ms. Ideally there would also popup an abort option after a configurable amount of time.
Yes, I can reproduce the freeze and it's logical than when you pass a never-ending method to a thread, the thread is blocked for ever. When a method is being evaluated, the description in the Debugging view changes to "'main' evaluating method..." Maybe we can make it more visible. Wait cursor is not appropriate, since you need to have the ability to use the mouse for other actions in the IDE. I do not think there is a clean way how to stop the evaluation of a method. It's just some code being executed. I can check if ThreadReference.popFrames() would do the job http://docs.oracle.com/javase/8/docs/jdk/api/jpda/jdi/com/sun/jdi/ThreadReference.html#popFrames-com.sun.jdi.StackFrame- but it does not work when there are some native methods on the stack and it can leave the application in an inconsistent state. IMHO in this case it's much safer to finish the debugger session and start again.
*** Bug 254366 has been marked as a duplicate of this bug. ***