Bug 235778 - Potential race condition computing resolved classpath
Summary: Potential race condition computing resolved classpath
Status: VERIFIED FIXED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 3.4   Edit
Hardware: PC Windows XP
: P3 normal (vote)
Target Milestone: 3.4.1   Edit
Assignee: Jerome Lanneluc CLA
QA Contact:
URL:
Whiteboard:
Keywords:
: 238448 (view as bug list)
Depends on:
Blocks:
 
Reported: 2008-06-05 05:17 EDT by Jerome Lanneluc CLA
Modified: 2008-08-28 12:37 EDT (History)
3 users (show)

See Also:

Attachments
Proposed fix for 3.4.1 (1.30 KB, patch)
2008-06-05 05:22 EDT, Jerome Lanneluc CLA 		no flags Details | Diff
Proposed fix for 3.3 maintenance (4.04 KB, patch)
2008-06-05 09:36 EDT, Jerome Lanneluc CLA 		no flags Details | Diff
Proposed fix for 3.5 (8.65 KB, patch)
2008-06-05 09:47 EDT, Jerome Lanneluc CLA 		no flags Details | Diff
View All 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 Jerome Lanneluc CLA 2008-06-05 05:17:20 EDT 
I20080603-2000

JavaProject.resolveClasspath(PerProjectInfo) has a potential race condition: if the raw classpath is changed while we are computing the resolved classpath, we will overwrite the new raw classpath with the previous one when setting the resolved classpath.
Comment 1 Jerome Lanneluc CLA 2008-06-05 05:22:43 EDT 
Created attachment 103712 [details]
Proposed fix for 3.4.1

This fix consists in checking that the raw classpath has not changed before we set the resolved classpath. If it has changed, let the resolved classpath to null. Callers are already protected against this case (they will use a temporary PerProjectInfo to compute the resolved classpath)
Comment 2 Philipe Mulet CLA 2008-06-05 05:25:32 EDT 
Do we have the same issue in 3.3?
Comment 3 Jerome Lanneluc CLA 2008-06-05 05:42:39 EDT 
(In reply to comment #2)
> Do we have the same issue in 3.3?
Yes we do. Do you want the proposed fix to be backported to 3.3.x?
Comment 4 Philipe Mulet CLA 2008-06-05 06:06:06 EDT 
+1 for backport to 3.3.x
Comment 5 Jerome Lanneluc CLA 2008-06-05 09:36:15 EDT 
Created attachment 103730 [details]
Proposed fix for 3.3 maintenance
Comment 6 Jerome Lanneluc CLA 2008-06-05 09:42:57 EDT 
Fix released in R3_3_maintenance branch
Comment 7 Jerome Lanneluc CLA 2008-06-05 09:47:52 EDT 
Created attachment 103734 [details]
Proposed fix for 3.5

Introduces synchronized methods (instead of synchronized blocks) + uses a timestamp to check if the raw classpath has changed
Comment 8 Jerome Lanneluc CLA 2008-06-25 04:20:51 EDT 
Fix from comment 1 released for 3.4.1
Comment 9 Jerome Lanneluc CLA 2008-06-25 07:07:56 EDT 
Fix from comment 7 released for 3.5M1
Comment 10 Jerome Lanneluc CLA 2008-06-26 02:21:59 EDT 
*** Bug 238448 has been marked as a duplicate of this bug. ***
Comment 11 Olivier Thomann CLA 2008-08-06 14:10:33 EDT 
Verified for 3.5M1 using I20080805-1307
Comment 12 Frederic Fusier CLA 2008-08-28 11:34:49 EDT 
Reopen to include the bug in the 3.4.1 verification process
Comment 13 Frederic Fusier CLA 2008-08-28 11:35:03 EDT 
.
Comment 14 Frederic Fusier CLA 2008-08-28 12:37:17 EDT 
Verified for 3.4.1 using build M20080827-2000.