Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 352455

Summary:

Eclipse crashes on java rename refactoring

Product:

[Eclipse Project] Equinox

Reporter:

Jelle.v <victoor.jelle>

Component:

Framework

Assignee:

equinox.framework-inbox <equinox.framework-inbox>

Status:

CLOSED DUPLICATE

QA Contact:

Severity:

critical

Priority:

CC:

john.arthorne, remy.suen, tjwatson

Version:

3.7

Target Milestone:

---

Hardware:

OS:

Windows XP

Whiteboard:

Attachments:

Description	Flags
threddump	none

Description Jelle.v

2011-07-19 09:24:44 EDT

Build Identifier: 20110615-0604

 My eclipse is crashing all the time, when I try to do a refactor rename. When I uncheck the options: 
- 'update similarly named variables and methods',
- 'update textual occurrences in comments and strings',
- 'update fully qualified names in non-Java text files';
I still get the same error.

eclipse.buildId=I20110613-1736
java.version=1.7.0
java.vendor=Oracle Corporation
BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=en_US
Framework arguments:  -product org.eclipse.epp.package.jee.product
Command-line arguments:  -os win32 -ws win32 -arch x86 -product org.eclipse.epp.package.jee.product -consoleLog

!ENTRY org.eclipse.jst.jsp.core 4 4 2011-07-19 14:32:20.608
!MESSAGE A workspace crash was detected. The previous session did not exit normally. Not using saved taglib indexes.

Reproducible: Always

Steps to Reproduce:
1. open eclipse
2. select a classname
3. do a rename

Comment 1 Remy Suen

2011-07-19 09:29:18 EDT

Please look for hs_err_pid crash logs. Alternatively, please try using Java 6 instead of Java 7.

Comment 2 Jelle.v

2011-07-19 09:30:14 EDT

Created attachment 199901 [details]
threddump

Comment 3 Jelle.v

2011-07-19 09:34:57 EDT

(In reply to comment #1)
> Please look for hs_err_pid crash logs. Alternatively, please try using Java 6
> instead of Java 7.

Using Java 6 causes the same problem (jdk1.6.0_23). There is not a hs_err_pid crash log since the eclipse instance hangs instead of crashing.
I have uploaded the threaddump and now I'm trying to upload the heap dump

Comment 4 John Arthorne

2011-07-19 15:33:03 EDT

(In reply to comment #3)
> Using Java 6 causes the same problem (jdk1.6.0_23). There is not a hs_err_pid
> crash log since the eclipse instance hangs instead of crashing.

I'm confused about whether you are experiencing a crash or a hang. The subject says crash, but your comment (and attached heap dump) suggest a hang/deadlock.

This looks related to locking in the extended log service:

"ModalContext" prio=6 tid=0x36291400 nid=0x5d0 in Object.wait() [0x3acdd000]
   java.lang.Thread.State: WAITING (on object monitor)
	at java.lang.Object.wait(Native Method)
	at java.lang.Object.wait(Object.java:503)
	at org.eclipse.equinox.log.internal.BasicReadWriteLock.writeLock(BasicReadWriteLock.java:36)

Comment 5 Jelle.v

2011-07-19 15:35:40 EDT

(In reply to comment #4)
> (In reply to comment #3)
> > Using Java 6 causes the same problem (jdk1.6.0_23). There is not a hs_err_pid
> > crash log since the eclipse instance hangs instead of crashing.
> 
> I'm confused about whether you are experiencing a crash or a hang. The subject
> says crash, but your comment (and attached heap dump) suggest a hang/deadlock.
> 
> This looks related to locking in the extended log service:
> 
> "ModalContext" prio=6 tid=0x36291400 nid=0x5d0 in Object.wait() [0x3acdd000]
>    java.lang.Thread.State: WAITING (on object monitor)
>     at java.lang.Object.wait(Native Method)
>     at java.lang.Object.wait(Object.java:503)
>     at
> org.eclipse.equinox.log.internal.BasicReadWriteLock.writeLock(BasicReadWriteLock.java:36)

Well it's kind of hard to say. I see eclipse crashing in my logs (... A workspace crash was detected....), but the application stays open. Whether to call it a crash or a deadlock/hangs is hard to say.

Comment 6 Thomas Watson

2011-07-20 09:42:10 EDT

You should probably open a separate bug against the m2e team.  It is not a good
idea for these two log redirectors to be pointing to each other through
logback.

*** This bug has been marked as a duplicate of bug 347183 ***