195939 – Deadlock during Refactor - Introduce Constant

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 195939 - Deadlock during Refactor - Introduce Constant

Summary: Deadlock during Refactor - Introduce Constant

Status:	CLOSED WORKSFORME

Alias:	None

Product:	java
Classification:	Unclassified
Component:	Hints (show other bugs)
Version:	7.0
Hardware:	PC Linux

Importance:	P3 normal (vote)
Assignee:	Jan Lahoda

URL:	http://wiki.netbeans.org/STS_68_Refac...
Keywords:	RANDOM

Depends on:
Blocks:

Reported:	2011-02-24 12:04 UTC by ttokoly
Modified:	2011-06-08 17:33 UTC (History)
CC List:	1 user (show)

See Also:
Issue Type:	DEFECT
Exception Reporter:

Attachments
thread dump (13.94 KB, text/plain) 2011-02-24 12:06 UTC, ttokoly	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 ttokoly 2011-02-24 12:04:37 UTC

Comment 1 ttokoly 2011-02-24 12:06:49 UTC

Created attachment 106406 [details]
thread dump

Comment 2 ttokoly 2011-02-24 12:16:28 UTC

1. Unzip a project default to some work directory - there is link:
http://wiki.netbeans.org/wiki/images/e/ec/Refactoring_STS_68_Refactoring.zip
2. Start IDE with a clean userdir
3. Invoke File | Open Project... action
4. Select unzipped projects default
5. Scanning structure of project should be performed (It takes a while)

6. Open file packageE.ClassB
7. Select constant 3 in the method statMethod()
8. Perform Refactor -> Introduce Constant
9. Uncheck Replace all occurrence and fill in a new name
10. Press OK

Deadlock shows when I uncheck Replace all occurence.

Product Version: NetBeans IDE Dev (Build 201102240001)
Java: 1.7.0-ea; Java HotSpot(TM) Client VM 21.0-b02
System: Linux version 2.6.32-28-generic running on i386; UTF-8; en_US (nb)

P.S. Sorry for empty description, I was miss-clicked.

Comment 3 ttokoly 2011-02-24 12:18:23 UTC

Note: According to thread dump, "repaint bug" has nothing to do with that.

Comment 4 David Strupl 2011-02-25 08:26:23 UTC

The thread dump does not indicate any deadlock. Just that the IDE was trying to show some dialog and waited for the dialog to close. Wasn't the dialog hidden behind your other windows?

It might look like a deadlock if the dialog was not there at all and the rest waited for it to close ...

Comment 5 ttokoly 2011-02-25 11:39:03 UTC

Hm, it's possible, but I can't tell for sure. It's random, so I can hardly reproduce it. If this happens to me one more time I'll let you know immediately. 

Between that, maybe you can lower the priority?

Comment 6 Jan Lahoda 2011-02-28 08:49:07 UTC

(In reply to comment #4)
> The thread dump does not indicate any deadlock. Just that the IDE was trying to
> show some dialog and waited for the dialog to close. Wasn't the dialog hidden
> behind your other windows?

Another possibility is that this is a JDK bug.

Comment 7 Jan Lahoda 2011-03-10 12:29:08 UTC

Last week, when I talked to the reporter, it seemed more like a JDK bug: after clicking at the checkbox, the dialog was not repainted anymore. The thread dump shows AWT waiting for next event. So far, I know only about one single case when this happened: reporter, did you see it again? Thanks.

Comment 8 ttokoly 2011-03-10 13:30:45 UTC

No, I don't met this bug anymore.

Comment 9 Marian Mirilovic 2011-04-08 08:34:58 UTC

Closing as worksforme ... Tomas reopen this issue if you meet it once again please. Thanks in advance.

Comment 10 Marian Mirilovic 2011-06-08 17:33:32 UTC

v/c