On Thu, Sep 27, 2012 at 12:30 PM, Philip Martin <philip.mar...@wandisco.com>wrote:
> stef...@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> ! *
