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

Bug 347408

Summary: Single bad entry breaks entire type hierarchy
Product: [Eclipse Project] JDT Reporter: Stephan Herrmann <stephan.herrmann>
Component: CoreAssignee: Stephan Herrmann <stephan.herrmann>
Status: CLOSED DUPLICATE QA Contact:
Severity: normal    
Priority: P3 CC: amj87.iitr, jarthana, Olivier_Thomann, srikanth_sankaran
Version: 3.7   
Target Milestone: 4.8 RC2   
Hardware: PC   
OS: Linux   
Whiteboard:
Attachments:
Description Flags
proposed fix none

Description Stephan Herrmann CLA 2011-05-27 04:24:39 EDT 
In the Object Teams test suite we have a recent regression
which manifests in lots of types missing in a type hierarchy.

I'm still investigating the root cause, but the symptom is much
more drastic than appropriate: inside method
IndexBasedHierarchyBuilder.buildFromPotentialSubtypes(..)
a JavaModelException will cause the loop over allPotentialSubTypes
to get "stuck" on the bad element.

Assume in line 306 an invalid currentProject causes a JavaModelException.
The exception will be caught below, but in that case currentProject will never
be advanced and each subsequent iteration of the surrounding for loop will
hit the same JME, causing all subsequent entries of allPotentialSubTypes to 
be skipped.
Comment 1 Stephan Herrmann CLA 2011-05-27 04:26:26 EDT 
Created attachment 196728 [details]
proposed fix

This simple change ensures that the loop properly advances
even in case of a JME.
Comment 2 Ayushman Jain CLA 2011-05-27 06:40:32 EDT 
The change is minor and looks safe. Though it may be too late for 3.7. Olivier, what do you think?
Comment 3 Olivier Thomann CLA 2011-05-27 08:39:56 EDT 
Is this a regression over 3.6.2 ? I don't think so. So even if this is annoying, I think this is a good candidate for 3.7.1. We are one week away from RC4. So I don't think this is serious enough to be fixed at that point.
Srikanth, what is your call ?
Comment 4 Stephan Herrmann CLA 2011-05-27 09:42:18 EDT 
(In reply to comment #3)
> Is this a regression over 3.6.2 ? I don't think so.

I don't thinks so, either.

If there is indeed a regression in JDT/Core the location
in IndexBasedHierarchyBuilder only causes that regression
to escalate.

I'll tell you more, once I found the time to investigate
the root cause. It was s.t. along the lines that the
primary working copy owner still served working copies
from a deleted project. Maybe this already rings a bell?
Any recent change that could produce such effects?
Comment 5 Stephan Herrmann CLA 2011-05-28 12:41:52 EDT 
OK, the root cause was not in JDT/Core. The Object Teams code was 
leaking a working copy.

I was just surprised that this leaked working copy would survive even
deletion of the containing project. Is that intended?

After 3.7.0 I will prepare a test case that demonstrates the issue.
Comment 6 Jay Arthanareeswaran CLA 2011-05-30 04:16:08 EDT 
(In reply to comment #5)
> I was just surprised that this leaked working copy would survive even
> deletion of the containing project. Is that intended?

I guess so. I found the following documentation from IWorkingCopy:

 * The client that creates a working copy is responsible for
 * destroying the working copy. The Java model will never automatically
 * destroy or close a working copy.
Comment 7 Eclipse Genie CLA 2019-01-12 12:19:09 EST 
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet.

If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.

--
The automated Eclipse Genie.
Comment 8 Stephan Herrmann CLA 2019-01-20 15:03:42 EST 
Looking at the code this was meanwhile fixed via bug 486979.

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