541595 - nsProfileLock::LockWithSymlink still has a race that can lead to data loss

Status: RESOLVED INCOMPLETE

(Core Graveyard :: Profile: BackEnd, defect)

Description

[David Fuchs]

User-Agent:       Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; InfoPath.2; .NET CLR 2.0.50727; .NET CLR 1.1.4322; .NET CLR 3.0.04506.30; .NET CLR 3.0.04506.648; OfficeLiveConnector.1.3; OfficeLivePatch.0.0; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)
Build Identifier: firefox-3.6.source.tar.bz2 21-Jan-2010 12:33 

Following on to 151188 and 76431, there's still a possible disaster scenario (albeit a bit hard to hit).  First, assume the system had previously crashed, and a symlink lock had been left behind.  Now, start up TWO processes, A and B.  Let them both run until they have just returned from the call to IsSymlinkStaleLock(), which returns "true" for both A and B.  Now, assume B stops getting cycles, while A continues for a bit.  The next thing A does is to unlink the symlink lock, and then create a new one with a call to symlink().  Then A goes happily on figuring it has the lock.  But now B starts getting cycles again, so it acts on the IsSymlinkStaleLock()==true value it had previously computed, and starts right in by unlinking the symlink lock. However, this is not the old, stale symlink anymore, it's A's nice new one.  But B goes blithely on, claiming the lock for itself, while A still figures it holds the lock.  

That's the bug; but also note also that the FIRST of A and B to call Unlock will cause the symlink lock to be removed, so now C can come along and get the lock, even though either A or B still thinks it has it.  And so on.

Reproducible: Always

Steps to Reproduce:
1. Start two browsers with breakpoint at the call to unlink() in LockWithSymlink
2. Cause both of them to hit the breakpoint.
3. Continue one of them just a bit, so it figures it holds the lock.
4. Single-step the second one, and note that it clobbers the symlink lock file.
Actual Results:  
Data loss, ala 76431.

Expected Results:  
Harmony.

Comment 1

[Benjamin Smedberg]

This bug is filed in a bugzilla component related to pre-Firefox code which no longer exists. I believe it is no longer relevant and I am therefore closing it INCOMPLETE.

If you believe that this bug is still valid and needs to be fixed, please reopen it and move it to the Toolkit:Startup and Profile System product/component.