Re: svn commit: r1404159 - /subversion/trunk/subversion/libsvn_subr/named_atomic.c

On Wed, Oct 31, 2012 at 5:38 PM, Julian Foad <julianfoad_at_btopenworld.com>wrote:

> Philip Martin:
>
> > stefan2_at_apache.org writes:
> >> + /* Sanitize (in case of data corruption)
> >> + */
> >> + if (new_ns->data->count > MAX_ATOMIC_COUNT)
> >> + new_ns->data->count = MAX_ATOMIC_COUNT;
> >
> > I'm still seeing a crash:
> >
> > 467 if (new_ns->data->count > MAX_ATOMIC_COUNT)
> > (gdb) p new_ns->data->count
> > $1 = -1382404098
>
> Also, if the count is "corrupted", I want to ask: are we sure it is then
> safe to adjust the count and carry on? (I haven't been paying close
> attention, I'm just asking.)
>

You are right. When we detect that someone messed
with our on-disk data, we should simply bail out instead
of trying to limp on. svnadmin recover is the place to
try to fix things (which we do since r1404163).

Changed in r1405772.

-- Stefan^2.

-- 
Certified & Supported Apache Subversion Downloads:
*
http://www.wandisco.com/subversion/download
*