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.
To reproduce problem: 1) Create new module suite and then add a module. 2) Right click on newly created module and New > Other > Module Development > Action 3) Click Next and next... Nb hangs.
Could you please attach thread dump while IDE hangs? http://wiki.netbeans.org/GenerateThreadDump
Created attachment 74059 [details] Thread dump
Hi. Thread dump attached. Thanks for your prompt reply.
Reassigning to apisupport for further evaluation. "anand1st" does that finish (after some time)? I've tried on Mac and that works.
Cannot reproduce on XP and tread dump does not show any apparent deadlock. EQ is busy scanning project classpath but running. Populating Category and Menu combos can take some time, can you try it once more and wait a bit longer? Wizard panel can do better in not blocking EQ, but that is not P1.
Not into 7.0 or next release. Feel free to reopen if more important than it seems.
Same problem here, only it's with 6.1 and 6.5 It freezes on the GUI registration screen. It seems to me that it's having trouble enumerating the pulldowns. Java starts really sucking up memory while it's happening. Entered GUI registration form for new action 19:23 At 19:30 still not completed and netbeans appears frozen Intel E7300 4GB ram Product Version: NetBeans IDE 6.1 (Build 200805300101) Java: 1.6.0_10; Java HotSpot(TM) Client VM 11.0-b15 System: Windows XP version 5.1 running on x86; Cp1252; en_US (nb) Userdir: C:\Documents and Settings\Jordan\.netbeans\6.1 Product Version: NetBeans IDE 6.5 (Build 200811100001) Java: 1.6.0_10; Java HotSpot(TM) Client VM 11.0-b15 System: Windows XP version 5.1 running on x86; Cp1252; en_US (nb)
Hi, Found something interesting. With Java 1.5.0_16, NB6.5 doesn't hang as long.. ~ 30 sec. In contrast, 30 mins is not enough to do this using Java 1.6.0_10 My machine specs: Windows XP SP3 on x86 using 2GB RAM. Can someone verify this? Thanks.
Hmm, even weirder, I did try this on JDK 1.6. 30 mins are of course unacceptable. Can someone from QA try this?
I think it is taking more time with Java 1.6 because of the HEAP SIZE issue. Maybe if Heap was increased to a larger amount, and if garbage collection was turned on, this should not happen. i guess JVM 1.6 itself, does lot of work on optimizations and stuffs, so it might suck up lot of memory for that, so guess heap size might be the issue, so i would suggest someone just trying to increase it and use netbeans, there is also a way to permenantly increase it, which is posted here http://developers.sun.com/docs/javacaps/installing/jcapsinstall.inst_increase_heap_size_t.html Balaji R
I'm not able to reproduce. Product Version: NetBeans IDE 6.5 (Build 200811100001) Java: 1.6.0_10; Java HotSpot(TM) Client VM 11.0-b15 System: Windows XP version 5.1 running on x86; Cp1252; en_US (nb) Maybe it is somehow relate to JCAPS? Do you use jcaps distribution?
Hi Balaji. Don't think it's the heap size. These are the options I am using: netbeans_default_options="-J-Dorg.glassfish.v3.installRoot=\"C:\Program Files\glassfish-v3-prelude\" -J-Dcom.sun.aas.installRoot=\"C:\Program Files\glassfish-v2ur2\" -J-client -J-Xverify:none -J-Xss2m -J-Xms32m -J-Xmx512m -J-XX:PermSize=32m -J-XX:MaxPermSize=200m -J-Dapple.laf.useScreenMenuBar=true -J-Dsun.java2d.noddraw=true -J-XX:+UseConcMarkSweepGC -J-XX:+CMSClassUnloadingEnabled -J-XX:+CMSClassUnloadingEnabled -J-XX:+UseParNewGC" I am not using JavaCAPS either. I'm just using the full Netbeans 6.5 installer. This is really bewildering. I cannot think why some users don't have problems but others do.
If you are able to reproduce it regularly could you take several thread dumps and attach them here?
Created attachment 74259 [details] Thread dump NB6.5
I have the same problem. It is impossible to create a new action in 6.5. Students in Warsaw on the NetBeans Platform course had the same problem too.
Upgraded to a P2 and added myself to the CC.
ok, when we have somebody "in house" to reproduce" then it should be easier to fix. I'm removing the INCOMPLETE keyword and marking as candidate for a patch.
I can reproduce this consistently. Come visit me and I will show you.
Hi, I've just installed the new JDK 1.6.0_11 and I'm not facing this problem anymore. Maybe it was issue with Java 1.6.0_10. If someone else who has the same problem can verify this and IF your problem is also fixed, perhaps we can resolve this issue. Regards, Anand.
Already working on it. Classpath scan can be quite long when started in (in)appropriate time, over 1 min. on my machine. Though not nearly as long as reported. Will check with gwielenga.
*** Issue 154162 has been marked as a duplicate of this issue. ***
Still happens to me on JDK 6u11. In my case, though, this only happens with Maven nbm projects.
After reading the comments I immediately updated both the JSE and JDK to v6u11 and increased the heap size to 2.5x its size, but this didn't resolve the issue. Specs: Windows Vista Home Premium SP1 Intel Core2Duo P8400 @ 2.26GHz 4GB Ram Netbeans 6.5 with no add-ons
I have add this same issue with 6.5. The ide hangs even when creating a New Project Template. I also noticed that everytime I create a new module, the layer file does not expand into subnodes and the <layer in context> node is not present any more. Just mentioning this in case it is related to the hang because creating an action, etc have to modify/parse the layer file nodes. The layer.xml seems ok.
Look up the "Libraries" section of the properties dialog box of the Module Suite. You will find that all the libraries are enabled. If you select just the ones you want, you will no longer see the hang. Although it is still a bug that all the libraries were suddenly enabled, sure did not expect that to happen. Deselecting for just the libraries you want is quite a pain.
Integrated into 'main-golden', will be available in build *200812110201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/8122256c95fd User: Richard Michalsky <rmichalsky@netbeans.org> Log: #153608: not fixed, just more logging
*** Issue 155187 has been marked as a duplicate of this issue. ***
The issue hasn't passed the nomination process for 65patch2 by cut-off date. It has been moved to 65patch3.
A workaround: allegedly appears only in 6.5 FCS, not in later builds.
"AWT-EventQueue-1" prio=6 tid=0x34ced000 nid=0xe4 runnable [0x35e2e000..0x35e2fd 94] java.lang.Thread.State: RUNNABLE at java.util.zip.ZipFile.open(Native Method) at java.util.zip.ZipFile.<init>(ZipFile.java:114) FWIW, if this issue is only reproducible on Windows, I'd suspect windows file-locking - some other process has locked whatever zipfile is being opened, and the event thread patiently waits forever for it to be released. Perhaps some kind of race condition in the filesystem impl?
I can reproduce it consistently on Ubuntu.
I notice that this problem is faced only with the full installer of Netbeans. With the J2SE only install, I am not facing this issue at all (in Windows or Linux). Tried deactivating most modules in the full netbeans installation to just my minimum requirements but this didn't help.
Is anyone still experiencing this bug in nightly build (or 6.5 patch 2)? If not, I'd suggest closing this one, cannot reproduce on development machine.
This continues to be a very serious issue for anyone using 6.5. Just last week I experienced it again, other people too, and not with the full distribution only. For anyone creating an action in 6.5, this is a P1, not a P2.
I am experiencing this issue for full installation of NB6.5. My specifications are: Product Version: NetBeans IDE 6.5 (Build 200811100001) Java: 1.6.0_11; Java HotSpot(TM) Client VM 11.0-b16 System: Windows XP version 5.1 running on x86; Cp1252; en_US (nb) Userdir: C:\Documents and Settings\tusharj\.netbeans\6.5 This is a P1 for any module developer with regards Tushar Joshi, Nagpur
Richard, what is the status of this issue ? I would like to include it into NB 6.5 Patch3, but based on discussion here, we are still not sure where the problem is, are we ?
I'm going to debug it on Geertjan's computer today, I'll know more then.
Created attachment 77537 [details] Profiler snapshot
Created attachment 77540 [details] Another snapshot - different spots in XML filesystem
Not a deadlock, loading XML layers and localized action names from large platform takes minutes, depending on size of the platform (profiler snapshots attached). Needs caching. Partial workaround is to use Java-only IDE or build NBM projects against custom platform with as few clusters as possible. I agree that initial impression for user with full IDE is terrible.
*** Issue 159948 has been marked as a duplicate of this issue. ***
pushed into core-main #b4a1a8776fe3 Layer filesystem is now cached for binary NB platforms, it should speed up New Action Wizard and <this layer in context> node expansion in suite, suite component and standalone module projects. Geertjan and others, please try it if it is acceptable, there are some minor improvements possible. Warning: cache is currently initialized first time it is needed and stored in userdir. It means that first use (with the same userdir) is not terribly faster as before. We could initialize cache sooner, e.g. when first apisupport projeect is loaded, but that would slow down users that will not use New Action Wizard. Progress bar displaying "Scanning NetBeans Platform layers..." shows up during initial scan, telling user what's happening. For NB.org modules will be done separately as part of issue #161884.
The status whiteboard "65fixes4-candidate" has been removed. At this time our proactive patches for the NetBeans 6.5.x IDE have concluded. If you own a Sun service plan contract for NetBeans, you may wish to contact Sun Service http://www.sun.com/contact/support.jsp to request a fix via the product defect escalation process. For more information on purchasing a Sun service plan contract for NetBeans, refer to the service plan item "Sun Software Service Plans (S3P) for Developers" in the Sun Service table found on our NetBeans Support Resources page http://www.netbeans.org/kb/support.html
Product Version: NetBeans IDE Dev (Build 200906031401) Java: 1.6.0_13; Java HotSpot(TM) Client VM 11.3-b02 System: Linux version 2.6.22-p4smp running on i386; UTF-8; cs_CZ (nb) Reproducible in above mentioned build - this needs to be done better (!). The idea how this could be improved: do we really need to scan all the XML files? Isn't it possible to add a wizard step prompting for the first "branch" and to explore only the single branch in the next step? This operation does not last so long in NB6.1 and the UI is much more responsive there... During the "NetBeans platform" course at MFF, this issue was highly visible and caused a lot of sighs (and kind of embarassed presenters:))...
Created attachment 83207 [details] Profiler snapshot from "Conditionally enabled action"
Created attachment 83208 [details] Thread Dump between 2. and 3. step of the wizard (1)
Created attachment 83209 [details] Threaddump 2/3 step (2)
According to the stacktrace it is issue #165862, which should be hopefully resolved shortly. A workaround is to run NB with disabled assertions (or to use RC1, which has assertions disabled by default).
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/2e3155445b2b User: Richard Michalsky <rmichalsky@netbeans.org> Log: cleanup after #153608, failing test
I had the same problem with the following combinations on Windows XP, on two different computers: NB 6.7.1 + jdk 1.6.0_10 NB 6.7.1 + jdk 1.5.0_20 I checked out Issue #: 153608 and Issue #: 165948 so I have tried all combinations of starting NB with -J-da. The problem showed up when starting from scratch and creating a new NetBeans Platform Application, and then a new Module, and then using New->Action on the module. However I found that when starting with the sample "Paint Application", then it works fine (<1s). Still when following the tutorial for "Paint Application" the problem is there. So I simply used File->New Project->Samples->NetBeans Modules->Paint Application to start with and then deleted the modules from Paint Application. But why do that make a difference?
One possible causes of the difference is that building platform layers cache takes some time first time a particular platform is used. However I just tried with NB 6.7.1 Full IDE on JDK 1.6.0_11 and I don't observe any significant differences between using PaintApp and generating clean project (and neither of it hangs for me). You may also be experiencing either issue #165862, which was fixed in 6.8 or issue #169396, which is still open. To seriously investigate I'd need profiler snapshot or at least a thread dump, see http://wiki.netbeans.org/GenerateThreadDump. With the snapshot, please don't reopen this bug but file new one, the underlying cause is likely different.