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.

Bug 250305 - Easily freeze debugger and the IDE itself
Summary: Easily freeze debugger and the IDE itself
Status: NEW
Alias: None
Product: debugger
Classification: Unclassified
Component: Java (show other bugs)
Version: 8.0.2
Hardware: PC Linux
: P3 normal (vote)
Assignee: Martin Entlicher
URL:
Keywords:
: 254366 (view as bug list)
Depends on:
Blocks:
 
Reported: 2015-02-09 08:49 UTC by bleun
Modified: 2015-08-14 10:25 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments
Constructed code to demonstrate issues (3.49 KB, text/x-java-source)
2015-02-09 08:49 UTC, bleun
Details
Exception thrown shortly after I wanted to see value of "hoverMe" variable in its tooltip (2.40 KB, text/plain)
2015-02-09 10:44 UTC, Jiri Kovalsky
Details
Self profiling snapshot taken during evaluation of the "hoverMe" variable value for tooltip. (58.16 KB, application/octet-stream)
2015-02-09 10:47 UTC, Jiri Kovalsky
Details

Note You need to log in before you can comment on or make changes to this bug.
Description bleun 2015-02-09 08:49:40 UTC
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
Comment 1 Jiri Kovalsky 2015-02-09 10:44:19 UTC
Created attachment 151897 [details]
Exception thrown shortly after I wanted to see value of "hoverMe" variable in its tooltip
Comment 2 Jiri Kovalsky 2015-02-09 10:47:00 UTC
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.
Comment 3 Martin Entlicher 2015-02-09 15:01:37 UTC
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...
Comment 4 bleun 2015-02-09 15:55:08 UTC
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.
Comment 5 Martin Entlicher 2015-02-09 18:00:58 UTC
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.
Comment 6 Martin Entlicher 2015-08-14 10:25:36 UTC
*** Bug 254366 has been marked as a duplicate of this bug. ***