On Thu, Sep 27, 2012 at 12:30 PM, Philip Martin
<philip.martin_at_wandisco.com>wrote:
> stefan2_at_apache.org writes:
>
> > Author: stefan2
> > Date: Wed Sep 26 16:56:58 2012
> > New Revision: 1390601
> >
> > URL: http://svn.apache.org/viewvc?rev=1390601&view=rev
> > Log:
> > Some clients, e.g. our JAVA tests, indirectly allocate DAG nodes in pools
> > that live longer than the corresponding FS pool. These nodes become
> invalid
> > as soon as the FS gets destroyed, so it is fine to invalidate them
> together
> > with the FS.
> >
> > However, those pools will hold a locks on the DAG cache and will try to
> > release these locks long after the cache got destroyed. Therefore, we
> must
> > keep a list of all locking pools and revoke their locks unconditionally
> if
> > the cache gets destroyed.
>
> The javahl tests are still crashing:
>
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 0x7ffff7fd9700 (LWP 11226)]
> 0x00007fffc6301ffc in unlock_cache (baton_void=0x7ffff4062550)
> at ../src/subversion/libsvn_fs_fs/tree.c:237
> 237 lock->cache->first_lock = lock->next;
> (gdb) bt
> #0 0x00007fffc6301ffc in unlock_cache (baton_void=0x7ffff4062550)
> at ../src/subversion/libsvn_fs_fs/tree.c:237
> #1 0x00007fffc7201e08 in ?? () from /usr/lib/libapr-1.so.0
> #2 0x00007fffc7200c1d in apr_pool_destroy () from /usr/lib/libapr-1.so.0
> #3 0x00007fffc72021df in apr_pool_destroy_debug () from
> /usr/lib/libapr-1.so.0
> #4 0x00007fffec08b3a6 in svn_client_update4 (result_revs=0x7ffff7fd6ff0,
> paths=0x7ffff40a1150, revision=0x7ffff7fd7140, depth=svn_depth_unknown,
> depth_is_sticky=0, ignore_externals=0, allow_unver_obstructions=0,
> adds_as_modification=1, make_parents=0, ctx=0x7ffff7dff0a0,
> pool=0x7ffff40a0028) at ../src/subversion/libsvn_client/update.c:629
> #5 0x00007fffec507392 in SVNClient::update (this=0x7ffff0102710,
> targets=...,
> revision=..., depth=svn_depth_unknown, depthIsSticky=false,
> makeParents=false, ignoreExternals=false, allowUnverObstructions=false)
> at ../src/subversion/bindings/javahl/native/SVNClient.cpp:337
> #6 0x00007fffec513566 in
> Java_org_apache_subversion_javahl_SVNClient_update (
> env=0x7ffff00081d0, jthis=0x7ffff7fd7a88, jtargets=0x7ffff7fd7a80,
> jrevision=0x0, jdepth=0x7ffff7fd7a70, jdepthIsSticky=0 '\000',
> jmakeParents=0 '\000', jignoreExternals=0 '\000',
> jallowUnverObstructions=0 '\000')
> at
> ../src/subversion/bindings/javahl/native/org_apache_subversion_javahl_SVNClient.cpp:448
>
> (gdb) p lock->cache
> $1 = (fs_fs_dag_cache_t *) 0x7ffff407c028
> (gdb) p lock->cache[0]
> Cannot access memory at address 0x7ffff407c028
>
>
I've been painfully aware of this. Today, I have been
finally able to reproduce the problem on one of my
machines. It turned out to be a silly copy-n-pasto.
r1390935 should fix it for good.
-- Stefan^2.
--
*
Join us this October at Subversion Live
2012<http://www.wandisco.com/svn-live-2012>
for two days of best practice SVN training, networking, live demos,
committer meet and greet, and more! Space is limited, so get signed up
today<http://www.wandisco.com/svn-live-2012>
!
*
Received on 2012-09-27 12:47:24 CEST