Philip Martin wrote:
> Branko Čibej <brane@xbc.nu> writes:
>
>
>> Philip, if you'd care to valgrind this some more, I'd appreciate it
>> very much. My Purify is totally useless...
>>
>
> Using trunk r18150 (i.e. post-merge) the import now works.
>
Ah, thanks!
> I've found another valgrind issue:
>
> $ rm -rf repo && svnadmin create repo --fs-type bdb
> $ svn ls svn://localhost/repo
>
> I'm running svnserve under valgrind:
>
> $ valgrind -q --db-attach=yes --num-callers=20 svnserve -Xr.
> ==1612== Invalid read of size 4
> ==1612== at 0x1BCEA066: svn_fs_bdb__get_panic (env.c:681)
> ==1612== by 0x1BCF2487: cleanup_fs_db (fs.c:125)
> ==1612== by 0x1BCF259E: cleanup_fs (fs.c:171)
> ==1612== by 0x1BCF2822: cleanup_fs_apr (fs.c:291)
> ==1612== by 0x1BACEF7C: pool_clear_debug (apr_pools.c:2027)
> ==1612== by 0x1BACF230: pool_destroy_debug (apr_pools.c:1450)
> ==1612== by 0x1BACEF46: pool_clear_debug (apr_pools.c:1367)
> ==1612== by 0x1BACF230: pool_destroy_debug (apr_pools.c:1450)
> ==1612== by 0x1BACF319: apr_pool_terminate (apr_pools.c:1269)
> ==1612== by 0x1BACF6FB: apr_terminate (start.c:82)
> ==1612== by 0x1BBB7B61: exit (exit.c:54)
> ==1612== by 0x804BE58: main (main.c:562)
> ==1612== Address 0x1BD537B8 is 16 bytes inside a block of size 60 free'd
> ==1612== at 0x1B906B04: free (vg_replace_malloc.c:152)
> ==1612== by 0x1BACF0CD: pool_clear_debug (apr_pools.c:1390)
> ==1612== by 0x1BACF230: pool_destroy_debug (apr_pools.c:1450)
> ==1612== by 0x1BACEF46: pool_clear_debug (apr_pools.c:1367)
> ==1612== by 0x1BACF230: pool_destroy_debug (apr_pools.c:1450)
> ==1612== by 0x1BACEF46: pool_clear_debug (apr_pools.c:1367)
> ==1612== by 0x1BACF230: pool_destroy_debug (apr_pools.c:1450)
> ==1612== by 0x1BACF319: apr_pool_terminate (apr_pools.c:1269)
> ==1612== by 0x1BACF6FB: apr_terminate (start.c:82)
> ==1612== by 0x1BBB7B61: exit (exit.c:54)
> ==1612== by 0x804BE58: main (main.c:562)
>
Grrr! I know what this is; the global pools that hold the cached BDB
environment structs get destroyed before the not-so-global one from
which the svn_fs_t was allocated. And I can't think of a way to fix that
ordering... it could be that the only way to solve this one is to
allocate the cached structs using malloc (they're reference-counted anyway).
--
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Jan 19 00:18:43 2006