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.
NetBeans IDE Dev (Build 200701091900) 1.5.0_11; Java HotSpot(TM) Client VM 1.5.0_11-b03 Windows XP version 5.1 running on x86 en_US (nb); Cp1252 Dual Core Description: ============ 1.create new Java Project (without main class) 2. select source package -> new file/folder -> other - properties - ok 3. insert e.g. 1000 keys with values in bundle 4. disable UI Gesture Collector (module manager - Testing Tools) 5. restart IDE 6. unroll tree nodes under bundle in project win 7. delete one of the nodes -> popup menu - delete IDE gets stuck and must be killed by task manager. Userdir is corrupted because if IDE is reopen and user tries to delete node from bundle in project win again, in every case an exception occurs. I tested it on two maschins - my It's dual core and on qa-man-xp - with two processors and it occurs every time. It passed on one processor computer. StackTrace when userdir is corrupted: ===================================== java.io.IOException at org.netbeans.modules.masterfs.Delegate.getLockForDelegate(Delegate.java:126) at org.netbeans.modules.masterfs.MasterFileObject.getOutputStream(MasterFileObject.java:156) at org.netbeans.modules.properties.PropertiesEditorSupport$Environment.outputStream(PropertiesEditorSupport.java:706) at org.openide.text.CloneableEditorSupport$1SaveAsReader.run(CloneableEditorSupport.java:775) Thread dump is in attachment.
Created attachment 37235 [details] thread_dump
Created attachment 37236 [details] stack_trace
Created attachment 37242 [details] reformatted 92230.txt
I attached a reformatted version of '92230.txt' because the first line of the original '92230.txt' is very very very... long and I had severe problems opening it in the some text editors.
Created attachment 37270 [details] better thread dump included
This bug has not been reproduced by deleting entries in the editor. It has only been reproduced when deleting an entry by invoking Delete action on the corresponding entry node.
The "hang" is caused by a blocked AWT-event-dispatching thread ("AWT-EventQueue-1") which is waiting on org.openide.nodes.Children.MUTEX. It needs read access but it cannot be provided - the same mutex is in write access in thread "Module-Actions" and (probably) the write access is kept forever.
It seems to be non-reproducible on single-core single-processor systems, sometimes reproducible on dual-core single-processor systems and always reproducible on dual-processor system (all running Windows XP).
Accepted.
Deleting properties from the node is a rare use-case, the issue is not new (code unchanged for more than a year), non-trivial fix => not a Milestone 6 stopper.
I cannot reproduce it after the recent change of the Properties module (I started using generics). I cannot reproduce it even on the machine on which I was able to reproduce it regularly.
I got the IllegalStateException (see attachment "reformatted 92230.txt") when I ran NetBeans with JDK 1.5.0_11 but not with JDK 6.
The IllegalStateException (see attachment "reformatted 92230.txt") is caused by a missing hashCode() method in class Element.ItemElem. But simple addition of the missing hashCode() method does not solve the whole issue.
Created attachment 38417 [details] thread dump after addition of the missing hashCode() method
Created attachment 38421 [details] full thread dump of busy JVM on node expansion
I attached a thread-dump of a busy JVM. I got to this state when I started NetBeans (JDK 1.5.0_11, missing hashCode() added, no generics) and then tried to expand the node representing the .properties file. The node did not expand and the computer had both CPUs at 100%.
The busy JVM described above is caused by a known bug #84906.
I found that the hang really occurs in the following snippet of code in method org.openide.nodes.Children.setEntries(...): --------------------------- % ----------------------------- // if there are old items in the map, remove them to // reflect current state map.keySet().retainAll(new HashSet<Entry>(this.entries)); --------------------------- % ----------------------------- The above call of retainAll(...) never returns. It runs forever which blocks the "Module-Actions" thread. This thread holds two locks and thus effective blocks the whole IDE.
For some reason, the Iterator returned by the above map.keySet() repetitively returns two instances of HashMap.Entry, only switching between these two. If I name the instances as #1 and #2, the iterator returns: #1 #2 #1 #2 #1 #2 ... and so on. I can see the following reasons for this behaviour: 1) Internal data structures of the HashMap are broken. This can be caused by: a) bug in the HashMap implementation b) some violent action called by the NetBeans code 2) Contents of the HashMap is repetitively modified while the iterator runs and the prevention mechanisms built into HashMap cannot detect it.
The cycle is caused by broken internal data structures of HashMap. In this concrete example, there are two instances of HashMap.Entry pointing (HashMap.Entry.next) at each other. Both these entries are at the same index of HashMap.table. Petr, could you help me with solving this issue? (Note that this issue is only reproducible on multicore/multiprocessor systems.)
This bug has the same root cause as bug #84906 - it is unsynchronized HashMap inside implementation of of org.openide.nodes.Children. *** This issue has been marked as a duplicate of 84906 ***