On 7/18/06, Philip Martin <philip@codematters.co.uk> wrote:
> That's fixed the mutex read error, but using trunk@20716 I still get:
>
> $ svnadmin create repo --fs-type bdb
> $ valgrind -q svnserve -Xr.
> $ svn ls svn://localhost/repo
>
> ==4171== Invalid read of size 4
> ==4171== at 0x41E927A: find_entry (apr_hash.c:259)
> ==4171== by 0x41E9797: apr_hash_set (apr_hash.c:342)
> ==4171== by 0x43F1D8E: svn_fs_bdb__close (env.c:606)
> ==4171== by 0x43FA882: cleanup_fs (fs.c:185)
> ==4171== by 0x43FA916: cleanup_fs_apr (fs.c:291)
> ==4171== by 0x41F211E: run_cleanups (apr_pools.c:2034)
> ==4171== by 0x41F143B: pool_clear_debug (apr_pools.c:1372)
> ==4171== by 0x41F1624: pool_destroy_debug (apr_pools.c:1457)
> ==4171== by 0x41F1423: pool_clear_debug (apr_pools.c:1369)
> ==4171== by 0x41F1624: pool_destroy_debug (apr_pools.c:1457)
> ==4171== by 0x41F16EC: apr_pool_destroy_debug (apr_pools.c:1499)
> ==4171== by 0x41F1241: apr_pool_terminate (apr_pools.c:1269)
> ==4171== Address 0x446D530 is 32 bytes inside a block of size 40 free'd
> ==4171== at 0x401D37E: free (vg_replace_malloc.c:233)
> ==4171== by 0x41F14EA: pool_clear_debug (apr_pools.c:1395)
> ==4171== by 0x41F1624: pool_destroy_debug (apr_pools.c:1457)
> ==4171== by 0x41F1423: pool_clear_debug (apr_pools.c:1369)
> ==4171== by 0x41F1624: pool_destroy_debug (apr_pools.c:1457)
> ==4171== by 0x41F16EC: apr_pool_destroy_debug (apr_pools.c:1499)
> ==4171== by 0x41F1241: apr_pool_terminate (apr_pools.c:1269)
> ==4171== by 0x41F26B7: apr_terminate (start.c:82)
> ==4171== by 0x42C1AE1: exit (exit.c:54)
> ==4171== by 0x804C057: main (main.c:698)
> ==4171==
> ==4171== Jump to the invalid address stated on the next line
> ==4171== at 0x41414141: ???
> ==4171== by 0x41E9797: apr_hash_set (apr_hash.c:342)
> ==4171== by 0x43F1D8E: svn_fs_bdb__close (env.c:606)
> ==4171== by 0x43FA882: cleanup_fs (fs.c:185)
> ==4171== by 0x43FA916: cleanup_fs_apr (fs.c:291)
> ==4171== by 0x41F211E: run_cleanups (apr_pools.c:2034)
> ==4171== by 0x41F143B: pool_clear_debug (apr_pools.c:1372)
> ==4171== by 0x41F1624: pool_destroy_debug (apr_pools.c:1457)
> ==4171== by 0x41F1423: pool_clear_debug (apr_pools.c:1369)
> ==4171== by 0x41F1624: pool_destroy_debug (apr_pools.c:1457)
> ==4171== by 0x41F16EC: apr_pool_destroy_debug (apr_pools.c:1499)
> ==4171== by 0x41F1241: apr_pool_terminate (apr_pools.c:1269)
> ==4171== Address 0x41414141 is not stack'd, malloc'd or (recently) free'd
> ==4171==
> ==4171== Process terminating with default action of signal 11 (SIGSEGV)
> ==4171== Access not within mapped region at address 0x41414141
> ==4171== at 0x41414141: ???
> ==4171== by 0x41E9797: apr_hash_set (apr_hash.c:342)
> ==4171== by 0x43F1D8E: svn_fs_bdb__close (env.c:606)
> ==4171== by 0x43FA882: cleanup_fs (fs.c:185)
> ==4171== by 0x43FA916: cleanup_fs_apr (fs.c:291)
> ==4171== by 0x41F211E: run_cleanups (apr_pools.c:2034)
> ==4171== by 0x41F143B: pool_clear_debug (apr_pools.c:1372)
> ==4171== by 0x41F1624: pool_destroy_debug (apr_pools.c:1457)
> ==4171== by 0x41F1423: pool_clear_debug (apr_pools.c:1369)
> ==4171== by 0x41F1624: pool_destroy_debug (apr_pools.c:1457)
> ==4171== by 0x41F16EC: apr_pool_destroy_debug (apr_pools.c:1499)
> ==4171== by 0x41F1241: apr_pool_terminate (apr_pools.c:1269)
> ==4171==
> ==4171== Invalid free() / delete / delete[]
> ==4171== at 0x401D37E: free (vg_replace_malloc.c:233)
> ==4171== by 0x43A211B: free_mem (dl-libc.c:217)
> ==4171== by 0x43A1E64: __libc_freeres (set-freeres.c:49)
> ==4171== by 0x40194C1: _vgnU_freeres (vg_preloaded.c:60)
> ==4171== by 0x41E927C: find_entry (apr_hash.c:259)
> ==4171== by 0x41E9797: apr_hash_set (apr_hash.c:342)
> ==4171== by 0x43F1D8E: svn_fs_bdb__close (env.c:606)
> ==4171== by 0x43FA882: cleanup_fs (fs.c:185)
> ==4171== by 0x43FA916: cleanup_fs_apr (fs.c:291)
> ==4171== by 0x41F211E: run_cleanups (apr_pools.c:2034)
> ==4171== by 0x41F143B: pool_clear_debug (apr_pools.c:1372)
> ==4171== by 0x41F1624: pool_destroy_debug (apr_pools.c:1457)
> ==4171== Address 0x4214CB0 is not stack'd, malloc'd or (recently) free'd
> Segmentation fault
Oops, I totally should have seen that before. Fixed in r20717, it's
basically another manifestation of the same problem as the mutex
thing.
I'm now able to run basic_tests.py over svnserve with a bdb 4.4 repos
with apr built with pool debugging and under valgrind with no errors,
so I think we're on the right track ;-)
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jul 18 18:46:46 2006