Mailing-List: contact users-help@subversion.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (athena.apache.org: local policy)
From: "Mark Raymond" <markr@raymonds.org.uk>
To: <users@subversion.apache.org>
References: <001b01cdb876$d7776430$86662c90$@raymonds.org.uk>
 <20121102183511.GE2947@lp-shahaf.local>
In-Reply-To: <20121102183511.GE2947@lp-shahaf.local>
Subject: RE: svnserve crash
Date: Fri, 2 Nov 2012 22:37:34 -0000
Message-ID: <001001cdb94a$a75a16b0$f60e4410$@raymonds.org.uk>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AQI8ULPTivD71o0v5bDc6zxS8j5yeQINz8OHlulXw1A=
Content-Language: en-gb

> Now, the first thing that jumps out is that some of the actual parameters
are 0x00000000 or 0x00001000; for example:
> #14  0x13f639fd8 in serve(conn=(svn_ra_svn_conn_st *) 0x00000000,
params=(serve_params_t *) 0x00000000, pool=(apr_pool_t *) 0x00000000) at
> which might suggest a stack smash, or just that this is how windows stack
traces normally work and I'm not aware of that convention.

I think the hex values here may be truncated; this is a 64-bit compile, and
those are 32 bits long.

I've now compiled a debug version and I attached Visual Studio to svnserve
to see what happens. The stack trace looked similar, except there's an extra
8 digits after each hex value which has non-zero numbers.

In debug mode, I get an assertion fail for _CrtIsValidHeapPointer, which
occurs due to this attempt to free memory:

utils->free(data.data);

on line 256 of plugins\db_berkeley.c in Cyrus SASL code. I've now found that
if I remove this line, then the problem disappears, and svnserve works fine
- though obviously this probably results in a memory leak!

I'm considering this solved for me now. I've tried to measure the memory
leak, and it seems each check out / commit leaks ~8KB, which is small enough
to not worry me, especially as I'll be rebooting the computer svnserve is on
regularly.

> Are you using 1.7.7?
Yes