> 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
