[prev in list] [next in list] [prev in thread] [next in thread] 

List:       cyrus-devel
Subject:    Re: sync_server RESERVE command
From:       Ken Murchison <murch () andrew ! cmu ! edu>
Date:       2007-09-25 12:49:32
Message-ID: 46F903DC.9010204 () andrew ! cmu ! edu
[Download RAW message or body]

Applied to CVS.


David Carter wrote:
> Two separate bugs fixes, against current 2.3 CVS.
> 
> The missing i++ means that we would have failed to RESERVE some messages 
> where a given GUID appears multiple times in a mailbox. Not a huge deal.
> 
> The missing (i < count) was potentially serious: we fall off the end of 
> the ids array where RESERVE doesn't involve the last message in a mailbox.
> 
> I think that we got away with it. My reasoning follows:
> 
> If you are really unlucky 12/20 bytes of allocated but uninitiated 
> memory (ids[count]) will match one of the GUIDs later in the mailbox. 
> This will cause cmd_reserve() to reserve that message and issue a 
> spurious response.
> 
> Fortunately sync_client will moan and then ignore the response if it 
> wasn't expecting the GUID. If it _was_ expecting the GUID then 
> sync_server has reserved a legitimate copy. In fact this should be 
> impossible. If sync_client wanted a message with that GUID, it would 
> have asked for that copy in that mailbox, so the ids array would have 
> been longer.
> 
> ids[count] is always allocated.
> 
> There is a one in hundred chance that ids[count+1] is not, which would 
> lead to a segmentation fault if ids[count] matched a GUID.
> 


-- 
Kenneth Murchison
Systems Programmer
Project Cyrus Developer/Maintainer
Carnegie Mellon University
[prev in list] [next in list] [prev in thread] [next in thread]