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

RE: svnserve crash

From: Mark Raymond <markr_at_raymonds.org.uk>
Date: Fri, 2 Nov 2012 22:37:34 -0000

> 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
Received on 2012-11-02 23:38:15 CET

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

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