Bug 165862 - NetBeans hangs when using New Action Wizard
NetBeans hangs when using New Action Wizard
Status: RESOLVED FIXED
Product: apisupport
Classification: Unclassified
Component: Project
6.x
All Windows XP
: P2 (vote)
: 6.x
Assigned To: rmichalsky
issues@apisupport
: API, API_REVIEW_FAST, PERFORMANCE
: 165948 (view as bug list)
Depends on:
Blocks: 28918 168450
  Show dependency treegraph
 
Reported: 2009-05-22 23:07 UTC by tomwheeler
Modified: 2010-10-01 20:47 UTC (History)
7 users (show)

See Also:
Issue Type: DEFECT
:


Attachments
thread dump taken after hang (23.78 KB, text/plain)
2009-05-22 23:08 UTC, tomwheeler
Details
proposed api change (11.29 KB, patch)
2009-06-08 11:07 UTC, rmichalsky
Details | Diff
patch v.2 with JG02 implemented (11.08 KB, patch)
2009-06-15 13:33 UTC, rmichalsky
Details | Diff
patch v.3 with JG02 implemented (10.93 KB, patch)
2009-06-16 13:39 UTC, rmichalsky
Details | Diff
New thread dump for 6.9.1 (20.92 KB, text/plain)
2010-10-01 15:50 UTC, stevedperkins
Details

Note You need to log in before you can comment on or make changes to this bug.
Description tomwheeler 2009-05-22 23:07:39 UTC
I came across this problem today using a nightly build from last week.  I upgraded to the latest nightly build
(200905221401) and can still reproduce it 100% of the time, at least in my current project.

Steps to reproduce: 

1.  Right-click the package node in a module of a platform application

2.  Select New -> Action from context menu

3.  Select the "Conditionally Enabled" (Use CookieAction) radio button.  I also note that it takes several seconds
between when I click that radio button until the point at which I can select a different value from the "Cookie
Class(es):" drop down.

4.  Click the "Next" button

At this point, I get the wait cursor and the Next button is depressed, but the wizard never advances to the next screen.
 Clicking Cancel or attempting to close the dialog has no effect and the Windows task manager shows that the
netbeans.exe process is using 50% of CPU (e.g. 100% of one CPU core) until I finally kill the process several minutes later.

I will attach a thread dump shortly.
Comment 1 tomwheeler 2009-05-22 23:08:42 UTC
Created attachment 82680 [details]
thread dump taken after hang
Comment 2 rmichalsky 2009-05-25 15:27:52 UTC
*** Issue 165948 has been marked as a duplicate of this issue. ***
Comment 3 rmichalsky 2009-05-26 08:38:42 UTC
Reproducible with enabled assertions, caused by http://hg.netbeans.org/main/rev/b8dcce795dc4. This should not happen in
production builds, however in beta assertions are on by default.

Tom please try to run NB with -J-da, if the problem disappears (there is a delay when wizard is run for the 1st time,
but there should be a progress bar showing "Scanning platform layers" or the like during scanning).

Jardo, any ideas? I guess we'll need to disable this in JarFS, otherwise we get bug reports in every subsequent
milestone or beta release.
Comment 4 Antonin Nebuzelsky 2009-05-26 11:00:20 UTC
Setting TM=6.8 unless we find out that disabling assertions does not help.
Comment 5 tomwheeler 2009-05-26 16:21:21 UTC
I have just confirmed that I cannot reproduce the error after disabling assertions (by changing -ea to -da in the
etc/netbeans.conf file) using the same copy of NetBeans as before.  To be clear, I can reproduce it 100% in a certain
project when assertions are enabled but it does not occur when assertions are disabled. 
Comment 6 rmichalsky 2009-06-08 11:05:49 UTC
Suggesting to introduce new RequestProcessor constructor with additional enableStackTraces parameter (true by default),
which allows to disable slow posting of tasks at the price of calls from posting thread missing in stack trace, even
with enabled assertions. JarFS would then use such a RP.

Patch with API change and usage in JarFS attached, please review.
Comment 7 rmichalsky 2009-06-08 11:07:02 UTC
Created attachment 83308 [details]
proposed api change
Comment 8 Jesse Glick 2009-06-09 18:13:22 UTC
Cause is rather 3b30abd0e2b6.


[JG01] Rather than introducing an API change, I would suggest just making RP turn off the stack traces when it seems
necessary for performance, so that clients do not need to worry about it. For example, if there are currently one or
more tasks in the processor's queue (or running), don't fill in the stack trace for a newly posted task. Or, disable
stack traces if another task was posted less than one second ago. Etc.

(I will assume that JarFileSystem really needs to post hundreds of tasks, rather than reusing one task and pushing work
items into a queue.)


[JG02] You would expect that if you pass an explicit enableStackTraces that this would control whether stack traces are
enabled for the task. Yet in the proposed patch this is ANDed with the assertions flag.
Comment 9 tomwheeler 2009-06-10 17:52:03 UTC
I am not sure if this is just a coincidence, but it appears that disabling assertions (by adding -J-da to
netbeans_default_options of my etc/netbeans.conf file) is no longer a workaround for NB 6.7 RC2.  

I have verified in the IDE log that -da is interpreted as a command line switch, but as when I am noticing the same
behavior as when filing the issue.  I can reproduce this five out of five times, at least on the following configuration:

    Product Version: NetBeans IDE 6.7 RC2 (Build 200906042131)
    Java: 1.6.0_12; Java HotSpot(TM) Client VM 11.2-b01
    System: Windows XP version 5.1 running on x86; Cp1252; en_US (nb)

I will be happy to provide any other information you'd find helpful (thread dump, startup logs, etc.).  

If there is indeed no longer a valid workaround, I would think the priority should be set to P1.
Comment 10 tomwheeler 2009-06-10 20:21:16 UTC
After I rebooted my computer, I have found that it RC2 no longers hangs.  I made no changes to the netbeans.conf file
since rebooting, so the flag was there both before and after.  Ah, the joys of MS Windows...anything can be fixed by
rebooting!
Comment 11 rmichalsky 2009-06-11 10:26:01 UTC
You're saving my day :). I tried it yesterday with RC2 on 3 different systems and the bug didn't show up - RC2 has
assertions disabled by default - so after your post I was already looking forward to hunting another irreproducible bug. 

There is still visible delay when switching wizard pages that blocks AWT thread and is sometimes detected by the IDE,
I'll speed that up as well.
Comment 12 rmichalsky 2009-06-11 12:29:33 UTC
JG01: Maybe a matter of opinion, I'd rather have an explicit api then behavior which does or doesn't do something based
on current load of the system. JarFS uses so many tasks to coalesce closing and re-opening of jars, a valid use IMHO.

JG02: ok, I'll revert meaning of the parameter.
Comment 13 Jesse Glick 2009-06-11 13:59:55 UTC
To JG01 - in general yes, but this behavior is not a documented or normally observable part of the API; it just a matter
of improving diagnostics in case of errors, which were rather poor before 6.7 (since stack traces from the field, e.g.
exception reporter, would not have the magic flag enabled). I would rather that API clients not have to know or think
about it at all; you would merely lose the extra diagnostics when RP was being used for many small tasks, which is
acceptable. As you say, a matter of opinion.
Comment 14 rmichalsky 2009-06-15 13:33:58 UTC
Created attachment 83584 [details]
patch v.2 with JG02 implemented
Comment 15 Jesse Glick 2009-06-16 00:58:28 UTC
JG02 continued (I guess, not sure what exactly you just changed) - 'disableStackTraces' uses the negative sense. Do not
do this. Parameter should be named 'enableStackTraces' or similar.

Anyway its Javadoc does not seem to be consistent with its name.

I think you did not address JG02 at all. What I meant was that if you passed this param, that boolean value should be
honored regardless of whether assertions are on or off. Assertion status should be used as a default value only when
calling the preexisting constructors.
Comment 16 rmichalsky 2009-06-16 13:38:23 UTC
> I think you did not address JG02 at all. What I meant was that if you passed this param, that boolean value should be
> honored regardless of whether assertions are on or off. Assertion status should be used as a default value only when
> calling the preexisting constructors.

I see, I misunderstood that. Hopefully will be finally ok.
Comment 17 rmichalsky 2009-06-16 13:39:54 UTC
Created attachment 83629 [details]
patch v.3 with JG02 implemented
Comment 18 Jesse Glick 2009-06-16 16:35:13 UTC
Remember that when using a new API from another module you must update the dependency.
Comment 19 rmichalsky 2009-06-17 10:24:45 UTC
Ooops, thanks for reminder. So if there are no further comments till tomorrow, I'll integrate.
Comment 20 rmichalsky 2009-06-18 12:56:18 UTC
Thanks for review, integrating into core-main #1fcb51732db3
Comment 21 rmichalsky 2009-06-18 13:01:59 UTC
left assigned to apireviews
Comment 22 rmichalsky 2009-06-18 13:03:20 UTC
ok
Comment 23 Quality Engineering 2009-06-19 07:46:01 UTC
Integrated into 'main-golden', will be available in build *200906190201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main-golden/rev/1fcb51732db3
User: Richard Michalsky <rmichalsky@netbeans.org>
Log: #165862: disabling slow stacktraces in JarFS, performance reasons
Comment 24 tomwheeler 2009-06-19 17:36:44 UTC
Verified using the following configuration (when assertions were enabled in netbeans.conf):

Product Version: NetBeans IDE Dev (Build 200906190201)
Java: 1.6.0_12; Java HotSpot(TM) Client VM 11.2-b01
System: Windows XP version 5.1 running on x86; Cp1252; en_US (nb)

The original problem is fixed, although I logged issue #167383 in response to the behavior I noticed while verifying
this one.
Comment 25 _ tboudreau 2009-09-29 00:34:53 UTC
Just ran into this today when doing an NB platform training, with two students running NetBeans 6.7.1 - but taking several thread dumps, the event thread 
was consistently stuck getting the modification date for a file inside a JAR file, so not completely sure if this is the same problem or a different one.
Comment 26 proktor 2010-09-10 22:04:40 UTC
I've got the same problem on 6.9.1.
Comment 27 Jaroslav Tulach 2010-09-11 20:43:58 UTC
Where's your thread dump then? Closing again, until more information is provided.
Comment 28 Jaroslav Tulach 2010-09-11 20:43:59 UTC
Where's your thread dump then? Closing again, until more information is provided.
Comment 29 Petr Jiricka 2010-09-13 08:33:11 UTC
> Closing again, until more information is provided.

In such a case the right resolution is INCOMPLETE, not FIXED.
Comment 30 Jaroslav Tulach 2010-09-13 10:41:54 UTC
I don't think so. The old bug is fixed. There is no indication the new problem is the same.
Comment 31 stevedperkins 2010-10-01 15:50:50 UTC
Created attachment 102225 [details]
New thread dump for 6.9.1
Comment 32 stevedperkins 2010-10-01 15:52:06 UTC
I too am experiencing the issue with the latest version of NetBeans (6.9.1).  I've attached a thread dump to the bug report.
Comment 33 Jesse Glick 2010-10-01 15:56:01 UTC
stevedperkins - this issue is closed. Any new problems you see may or may not be related. "Livelocks" and similar freezes are best reported using the slowness detector, which produces a profile aggregated from many samples; but a manual thread dump is still useful for freezes with no CPU activity, such as deadlocks, or code waiting for network connections - in that case open a fresh issue report so that it can be tracked independently.
Comment 34 stevedperkins 2010-10-01 20:47:06 UTC
Err... okaaay.  I was responding to comment #27, indicating that the admin was closing "until" a thread dump or more information was provided.  At any rate, I've created a new bug report.  If anyone else dealing with this application behavior likewise stumbles across this page through a Google search, continue onward to that bug at http://netbeans.org/bugzilla/show_bug.cgi?id=190713


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo