Bug 92230 - IDE gets stuck during deleting keys in properties
IDE gets stuck during deleting keys in properties
Status: RESOLVED DUPLICATE of bug 84906
Product: utilities
Classification: Unclassified
Component: Properties
6.x
All All
: P1 (vote)
: 6.x
Assigned To: Marian Petras
issues@utilities
: RANDOM, THREAD
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2007-01-10 15:28 UTC by Jana Maleckova
Modified: 2007-02-14 14:50 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
:


Attachments
thread_dump (13.46 KB, text/plain)
2007-01-10 15:29 UTC, Jana Maleckova
Details
stack_trace (96.40 KB, text/plain)
2007-01-10 15:31 UTC, Jana Maleckova
Details
reformatted 92230.txt (98.10 KB, text/plain)
2007-01-10 18:44 UTC, Marian Petras
Details
better thread dump included (13.61 KB, text/plain)
2007-01-11 13:11 UTC, Jana Maleckova
Details
thread dump after addition of the missing hashCode() method (13.60 KB, text/plain)
2007-02-13 10:00 UTC, Marian Petras
Details
full thread dump of busy JVM on node expansion (11.87 KB, text/plain)
2007-02-13 10:21 UTC, Marian Petras
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jana Maleckova 2007-01-10 15:28:07 UTC
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.
Comment 1 Jana Maleckova 2007-01-10 15:29:36 UTC
Created attachment 37235 [details]
thread_dump
Comment 2 Jana Maleckova 2007-01-10 15:31:16 UTC
Created attachment 37236 [details]
stack_trace
Comment 3 Marian Petras 2007-01-10 18:44:07 UTC
Created attachment 37242 [details]
reformatted 92230.txt
Comment 4 Marian Petras 2007-01-10 18:45:53 UTC
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.
Comment 5 Jana Maleckova 2007-01-11 13:11:31 UTC
Created attachment 37270 [details]
better thread dump included
Comment 6 Marian Petras 2007-01-11 14:37:10 UTC
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.
Comment 7 Marian Petras 2007-01-11 14:46:39 UTC
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.
Comment 8 Marian Petras 2007-01-11 15:14:44 UTC
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).
Comment 9 Marian Petras 2007-01-11 20:05:09 UTC
Accepted.
Comment 10 Marian Petras 2007-01-12 11:14:48 UTC
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.
Comment 11 Marian Petras 2007-01-19 16:00:36 UTC
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.
Comment 12 Marian Petras 2007-02-13 08:06:20 UTC
I got the IllegalStateException (see attachment "reformatted 92230.txt") when I
ran NetBeans with JDK 1.5.0_11 but not with JDK 6.
Comment 13 Marian Petras 2007-02-13 09:44:15 UTC
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.
Comment 14 Marian Petras 2007-02-13 10:00:11 UTC
Created attachment 38417 [details]
thread dump after addition of the missing hashCode() method
Comment 15 Marian Petras 2007-02-13 10:21:47 UTC
Created attachment 38421 [details]
full thread dump of busy JVM on node expansion
Comment 16 Marian Petras 2007-02-13 10:24:58 UTC
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%.
Comment 17 Marian Petras 2007-02-13 14:00:31 UTC
The busy JVM described above is caused by a known bug #84906.
Comment 18 Marian Petras 2007-02-13 15:46:56 UTC
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.
Comment 19 Marian Petras 2007-02-13 17:07:04 UTC
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.
Comment 20 Marian Petras 2007-02-13 17:31:18 UTC
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.)
Comment 21 Marian Petras 2007-02-14 14:50:56 UTC
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 ***


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