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.
When I switch project (Project Manager -> Open), the IDE hangs. There is no activity on the runide process (memory doesn't increase, and no CPU time is used). It doesn't always happen, but happens very often, and sometimes I have to restart the IDE 5/6 times before I can change. I am using JDK 1.4.1_01 on Windows XP, but I have seen this problem also on Windows 2000.
Gabriele, please, make a Full Thread Dump when the IDE freezes and attach it to this report. Otherwise I can do almost nothing for you. Here are steps how to get FTD: 1. run IDE using the runide.exe (it will open the console window) 2. enlarge the screen buffer size; use the console window's system menu; set with = 1024, height = 9999 3. reproduce the state when IDE is frozen 4. press CTRL + Break on the console window; it will produce the FTD 5. copy/paste the FTD to some file and attach this file to your report Thanks a lot for you help.
I have tried for an hour this morning, and of course wasn't able to reproduce it. I also upgraded to JDK 1.4.1_02, so it may have disappeared because of that. I'll keep running using runide: hopefully sooner or later it'll happen again.
OK, assignig the RANDOM keyword and leaving still open for some time to gather more information.
This happens to me quite often. I'm using NetBeans 3.5 build 200303202210 under Linux 2.4.19 with Blackdown JDK 1.4.1-01. I've attached a thread dump showing a deadlock.
Created attachment 9663 [details] Thread dump showing deadlock.
It seems it is deadlock in window system. I reassign it. The problem is that creating instance of Mode (call WorkspaceImpl.addMode()) invokes WorkspaceImpl.getModes().
I am still seeing this with 3.5 rc1 (just happened). I took a thread dump and can post it if you like.
Yes please. Thanks.
Created attachment 10338 [details] Thread dump showing deadlock (NB 3.5 rc1, JDK 1.4.2-beta, Linux 2.4.20))
I am still seeing this in 3.5 rc2, will it be fixed before 3.5 goes gold? I think this is a serious issue that will affect people's opinion of NetBeans' quality, and would like to see the priority raised. I have another thread dump if you need it.
WorkspaceContext is listening to changes in modes on Workspace -> When mode is added from inside loading of mode -> it can trigger loading of workspace from inside loading of mode. Fix breaks this: WorkspaceContext now handles PROP_MODES event asynchronously. I will attach binary patch. Please add it to lib/patches (NB 3.5) and test if deadlock still happens. Fix will go to main trunk. I am afraid it is too late to fix it in NB 3.5.
Created attachment 10463 [details] Binary patch
Hi Glenn, in my opinion it's too late to fix it for 3.5/S1S5, we are nearly the release day. We are not able to reproduce your problem and only two users have reported that problem. If it is still happened, please use Mareks attached patch, thanks for report. It will be fixed for next releases.
Created attachment 10571 [details] Diff of patch
To happen WorkspaceContext class must be instantiated -> propertyChange() is called. WorkspaceContext can be instantiated for example by Tools -> Options by expanding nodes IDE Configuration -> Look and Feel -> Workspaces -> Editing, .... Fix posts processing of PROP_MODES to AWT thread using invokeLater() -> PROP_MODES is processed asynchronously. Fixed in main trunk: core/windows/src/org/netbeans/core/windows/nodes/WorkspaceContext.java r.1.3
verified in [nb_dev](200306110100)
Glenn mentioned this bug on nbusers as being an especial problem in 3.5. Looking at the patch, I see that the only change is wrapping a block in SwingUtilities.invokeLater. Candidate for the SIMPLEFIX keyword?
I think fix is safe. (Updating UI can be made asynchronously.)
Then add a SIMPLEFIX keyword and don't forget about it for next bugfix release.
Ok. Done.