Disabling the FSFS noderev cache makes the FAIL become a PASS:
[[[
Index: subversion/libsvn_fs_fs/caching.c
===================================================================
--- subversion/libsvn_fs_fs/caching.c (revision 1029228)
+++ subversion/libsvn_fs_fs/caching.c (working copy)
@@ -233,7 +233,7 @@ svn_fs_fs__initialize_caches(svn_fs_t *fs,
warn_on_cache_errors, fs, pool));
/* initialize node revision cache, if caching has been enabled */
- if (svn_fs__get_global_membuffer_cache())
+ if (svn_fs__get_global_membuffer_cache() && getenv("CACHE_NODE_REVS"))
{
SVN_ERR(svn_cache__create_membuffer_cache(&(ffd->node_revision_cache),
svn_fs__get_global_membuffer_cache(),
]]]
Historically, the failure started at r983760, which added that cache.
Daniel Shahaf wrote on Sat, Oct 30, 2010 at 19:13:08 +0200:
> Stefan Fuhrmann wrote on Sat, Oct 30, 2010 at 18:03:48 +0200:
> > On 30.10.2010 17:01, Daniel Shahaf wrote:
> >> Looks like at least one test fails:
> >>
> >> [[[
> >> lp-shahaf,14:svn/performance% ../runctest fs fs 22
> >> subversion/tests/libsvn_fs/fs-test.c:3411: (apr_err=160000)
> >> subversion/tests/libsvn_fs/fs-test.c:3229: (apr_err=160000)
> >> svn_tests: Error validating revision 1 (youngest is 3)
> >> subversion/tests/svn_test_fs.c:492: (apr_err=160000)
> >> svn_tests: Repository tree does not look as expected.
> >> Corrupt entries:
> >> A/D/G/rho
> >> Missing entries:
> >> Extra entries:
> >>
> >> FAIL: lt-fs-test 22: after each commit, check all revisions
> >> zsh: exit 1 ../runctest fs fs 22
> >> ]]]
> >>
> >> I haven't tested yet whether it's due to the commits this morning or to
> >> something else.
> > Hm. The tests run fine here. But I'm testing with FSFS only
> > and I'm using plain "make -j && make check" with no magic
> > environment variables set.
>
> I ran 'make davautocheck' (which would have tested FSFS), and I build
> with "-DSVN_FS_FS_DEFAULT_MAX_FILES_PER_DIR=4 -DPACK_AFTER_EVERY_COMMIT"
> in CFLAGS.
>
> Can you reproduce the FAIL with these CFLAGS set?
>
> >> Stefan, can you guess what might be causing this?
> >>
> > This is typically caused by stream_readline() not detecting
> > or handling EOF properly. You could try to replace just that
> > function with /trunk code and see what happens.
>
> It fails in the same way; see attached.
Received on 2010-10-31 02:09:07 CET