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

Bug 260416

Summary: multiple attempts at locking a Location cause release not to work
Product: [Eclipse Project] Equinox Reporter: Thomas Watson <tjwatson>
Component: FrameworkAssignee: Thomas Watson <tjwatson>
Status: RESOLVED FIXED QA Contact:
Severity: normal    
Priority: P3 CC: jeffmcaffer, pradeepb, simon_kaegi
Version: 3.5   
Target Milestone: 3.5 M5   
Hardware: PC   
OS: Windows XP   
Whiteboard:
Attachments:
Description Flags
proposed fix none

Description Thomas Watson CLA 2009-01-08 11:37:52 EST 
performing multiple attempts at locking a location cause the release operation to do nothing.  For example:

Location testLocation = ...

testLocation.lock();  // will successfully lock
testLocation.lock();  // will return false because the location is already locked
testLocation.lock();  // will return false because the location is already locked
testLocation.release(); // should release the original lock
testLocation.lock();  // will return false even though release was called


This is because the BasicLocation.lock() implementation will end up nulling the locker field out when lock() is called on the same Location object without releasing.  This causes release to do nothing but the nio FileLock will still be locked.
Comment 1 Thomas Watson CLA 2009-01-08 11:43:58 EST 
Created attachment 121977 [details]
proposed fix

The fix is to check if the Location is locked before attempt to lock the location.
Comment 2 Pradeep Balachandran CLA 2009-01-08 13:14:26 EST 
Good catch.

I would have run into this yesterday when I added similar tests in the ProfileRegistryTest for in-process locking via same thread (as part of bug 257654), but I didn't exercise this case, as there I needed different semantics - the second call to lock() to return true as I know for sure it is from the same thread (which is the existing behavior). So I ended up short-circuiting it in the local lock() method (that internally calls Location.lock()). In this case it is fine as there was one more layer that blocks it if the request was from a different thread.
Comment 3 Simon Kaegi CLA 2009-01-08 14:18:46 EST 
Wow that's brutal. We might want to consider back-porting the fix.

+1 to the patch and tests
Comment 4 Thomas Watson CLA 2009-01-08 15:02:34 EST 
This bug has been around since 3.0.  I am reluctant to backport to 3.4.2 given how late we are in the cycle.  Jeff, thoughts?

Patch released to HEAD.