[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Race in svn_atomic_namespace__create

From: Philip Martin <philip.martin_at_wandisco.com>
Date: Mon, 29 Oct 2012 23:11:57 +0000

Stefan Fuhrmann <stefan.fuhrmann_at_wandisco.com> writes:

> On Mon, Oct 29, 2012 at 10:46 PM, Philip Martin
> <philip.martin_at_wandisco.com>wrote:
>
>> Philip Martin <philip.martin_at_wandisco.com> writes:
>>
>> > Philip Martin <philip.martin_at_wandisco.com> writes:
>> >
>> >> I can't see any order in which we can do attach/create that doesn't have
>> >> a similar race. I think the best solution is a short loop trying
>> >> attach-create a few times before giving up.
>> >
>> > I've committed a loop in r1403463. That doesn't fix the race but it is
>> > now very unlikely to fail.
>>
>
> The creation code is protected by a repo-global lock/unlock pair.
> So, in theory, there should be no race condition.

Which lock and where? Does this lock out other processes?

>> I've just observed the same failure with the looping code. I'm not sure
>> what is wrong. I suppose there is a window during the creation process
>> where the file exists, so the create fails, but the memory is not yet
>> ready, so the attach also fails. If one process is in this state
>> another process might loop around 10 times and have both create and
>> attach fail. Perhaps a short and/or random delay would help?
>>
>
> It's on my TODO list to identify the root cause of this issue.

I think it must be the window between

     apr_file_open( APR_EXCL )

and

     mmap( MAP_SHARED )

in apr_shm_create. During that period any other process will see both
apr_shm_create and apr_shm_attach fail. But that would imply that your
process lock isn't working.

-- 
Certified & Supported Apache Subversion Downloads:
http://www.wandisco.com/subversion/download
Received on 2012-10-30 00:12:34 CET

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.