You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Philip Martin <ph...@wandisco.com> on 2012/09/27 12:30:02 UTC
Re: svn commit: r1390601 - /subversion/trunk/subversion/libsvn_fs_fs/tree.c
stefan2@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
--
Philip
Re: svn commit: r1390601 - /subversion/trunk/subversion/libsvn_fs_fs/tree.c
Posted by Stefan Fuhrmann <st...@wandisco.com>.
On Thu, Sep 27, 2012 at 12:30 PM, Philip Martin
<ph...@wandisco.com>wrote:
> stefan2@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>
!
*