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

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

From: Stefan Fuhrmann <stefan.fuhrmann_at_wandisco.com>
Date: Mon, 5 Nov 2012 13:46:20 +0100

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
*
Received on 2012-11-05 13:46:53 CET

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