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 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.
Created attachment 82680 [details] thread dump taken after hang
*** Issue 165948 has been marked as a duplicate of this issue. ***
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.
Setting TM=6.8 unless we find out that disabling assertions does not help.
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.
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.
Created attachment 83308 [details] proposed api change
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.
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.
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!
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.
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.
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.
Created attachment 83584 [details] patch v.2 with JG02 implemented
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.
> 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.
Created attachment 83629 [details] patch v.3 with JG02 implemented
Remember that when using a new API from another module you must update the dependency.
Ooops, thanks for reminder. So if there are no further comments till tomorrow, I'll integrate.
Thanks for review, integrating into core-main #1fcb51732db3
left assigned to apireviews
ok
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
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.
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.
I've got the same problem on 6.9.1.
Where's your thread dump then? Closing again, until more information is provided.
> Closing again, until more information is provided. In such a case the right resolution is INCOMPLETE, not FIXED.
I don't think so. The old bug is fixed. There is no indication the new problem is the same.
Created attachment 102225 [details] New thread dump for 6.9.1
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.
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.
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