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.

Bug 186559 - refactoring class name hangs netbeans.
Summary: refactoring class name hangs netbeans.
Status: NEW
Alias: None
Product: third-party
Classification: Unclassified
Component: -- Other -- (show other bugs)
Version: 6.x
Hardware: PC Windows XP
: P1 normal (vote)
Assignee: issues@third-party
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-05-23 15:42 UTC by sguha
Modified: 2010-05-24 07:11 UTC (History)
3 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:

Attachments
netbeans snapshot created using jvisualvm for refactor hang (30.65 KB, application/octet-stream)
2010-05-23 15:44 UTC, sguha 		Details
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description sguha 2010-05-23 15:42:28 UTC 
2. 
Netbeans IDE 6.8 downaloaded and updated. 
About box showed:
Product Version: NetBeans IDE 6.8 (Build 200912041610)
Java: 1.6.0_20; Java HotSpot(TM) Client VM 16.3-b01
System: Windows XP version 5.1 running on x86; Cp1252; en_US (nb)
Userdir: C:\Documents and Settings\Administrator\.netbeans\6.8
3.
Create a new java project with default class name Main

4. 
Tried refactoring the class name Main to SwingList

5.
Preview of refactoring worked fine. 

6. 
"Do refactoring" operation hangs, with a modal dialog.

7.
Must kill netbeans to do anything else. 

8.
Attached application snapshot taken by jvisualvm 

9. 
Observe the block in the following thread dump, taken by jvisualvm


"Parsing & Indexing Loop (200912041610)" prio=6 tid=0x040f2000 nid=0x1c78 waiting for monitor entry [0x0802f000]
   java.lang.Thread.State: BLOCKED (on object monitor)
	at org.openide.loaders.DataObject$Registry.getModifiedSet(DataObject.java:1174)
	- waiting to lock <0x19fa0fd8> (a java.util.Collections$SynchronizedSet)
	at org.netbeans.modules.java.source.parsing.SourceFileObject.isModified(SourceFileObject.java:324)

10.
The bugzilla you are using has a data loss problem: 
I have to enter this bug twice. 

Thanks
sguha
Comment 1 sguha 2010-05-23 15:44:55 UTC 
Created attachment 99356 [details]
netbeans snapshot created using jvisualvm for refactor hang

Bugzilla Attachement, did not work when the 
bug was created.
I have to again add attachment. 
Hope it works this time. 
- sguha
Comment 2 Jan Lahoda 2010-05-24 07:00:29 UTC 
The deadlock is between:
	at javax.swing.SwingUtilities.invokeAndWait(SwingUtilities.java:1320)
	at jindent.plugin.netbeans.NbUtils.getMainWindow(NbUtils.java:30)
	at jindent.plugin.netbeans.NbJindentThread.<init>(NbJindentThread.java:22)
	at jindent.plugin.netbeans.FormatterUtil.init(FormatterUtil.java:78)
	at jindent.plugin.netbeans.FormatterUtil.<init>(FormatterUtil.java:57)
	at jindent.plugin.netbeans.FormatterUtil.getInstance(FormatterUtil.java:62)
	at jindent.plugin.netbeans.listener.JindentChangeListener.stateChanged(JindentChangeListener.java:42)
	at org.openide.util.ChangeSupport.fireChange(ChangeSupport.java:130)
	at org.openide.util.ChangeSupport.fireChange(ChangeSupport.java:116)
	at org.openide.loaders.DataObject$ModifiedRegistry.add(DataObject.java:1215)
	at org.openide.loaders.DataObject$ModifiedRegistry.add(DataObject.java:1186)
	at java.util.Collections$SynchronizedCollection.add(Collections.java:1577)
	- locked <0x19fa0fd8> (a java.util.Collections$SynchronizedSet)


and (in AWT):
	at org.openide.loaders.DataObject$Registry.getModifiedSet(DataObject.java:1174)
	- waiting to lock <0x19fa0fd8> (a java.util.Collections$SynchronizedSet)
	at org.openide.actions.SaveAllAction$ModifiedListL$1.run(SaveAllAction.java:144)


This should IMO be solved in jindent.plugin (SwingUtilities.invokeAndWait is extremely dangerous and should be avoided). Passing to data systems which is the second lock in the deadlock for possible further checks.
Comment 3 David Strupl 2010-05-24 07:09:02 UTC 
The problem is in jindent plugin. It deadlocks because of using invokeAndWait ...
Comment 4 David Strupl 2010-05-24 07:11:07 UTC 
Jardo please check the thread dump. They are calling getMainWindow ... I don't know whether it is ok or not ....
Comment 5 David Strupl 2010-05-24 07:11:59 UTC 
Urgh, it their getMainWindow, anyway ....