Bug 59969 - Deadlock in code assist of New Class dialog
Summary: Deadlock in code assist of New Class dialog
Status: RESOLVED WORKSFORME
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 3.0   Edit
Hardware: PC Linux-GTK
: P3 normal (vote)
Target Milestone: 3.0 M9   Edit
Assignee: Kent Johnson CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-04-26 12:12 EDT by Michael Valenta CLA
Modified: 2004-05-05 10:52 EDT (History)
0 users

See Also:


Attachments
Stack trace (12.63 KB, text/plain)
2004-04-26 12:12 EDT, Michael Valenta CLA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Valenta CLA 2004-04-26 12:12:00 EDT
I was using code assist in the New Class dialog to get the package for a
superclass. When doing so a deadlock occured (using build I20040422). I will
attach the stacktrace.
Comment 1 Michael Valenta CLA 2004-04-26 12:12:24 EDT
Created attachment 9963 [details]
Stack trace
Comment 2 Dirk Baeumer CLA 2004-04-26 13:20:05 EDT
Both blocked threads are waiting for a look owned by the Java indexer:

ThreadName=main(0x805247c)
Status=Blocked
Monitor=0x809e3a8 (Object monitor for 
org/eclipse/jdt/internal/core/search/indexing/IndexManager @ 0x4249a408)
Count=1
Owner=Java indexing(0x831cd00)

However the Java Indexer thread doesn't seem to own a look (at least from the 
VM dump).

Both code ends are owned be JDT/Core. Philippe is there anything special we can
do in JDT/UI (look ordering). I looked into it and it doesn't seem that we 
are aquiring and special looks except a synchronized on the ICodeSelect we 
call codeSelect on.
Comment 3 Kent Johnson CLA 2004-05-04 15:49:49 EDT
The 2 waiting threads appear to be waiting for the monitor for the 
IndexManager since they're calling getIndex(), which is a synchronized 
method... but there is no thread in the trace which shows the IndexManager 
doing anything.
Comment 4 Kent Johnson CLA 2004-05-05 10:52:24 EDT
Closing... talked to McQ & we both agree that this must be a VM problem.

For the 2 threads to be waiting on the monitor of the IndexManager, there must 
be a thread in which the IndexManager is doing something.

Without it just looks like the VM forgot to release one of the 2 waiting 
threads.