You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Nathan Hartman <ha...@gmail.com> on 2019/12/24 21:38:59 UTC
Makefile.svn: a dumb question
When running the regression test suite via the 'svn-check' target of
tools/dev/unix-build/Makefile.svn, is there a convenient way to see a
"All tests successful"-type summary at the very end?
That is to say, is there a better way than what I'm doing now,
which is:
$ cat tests.log.* | grep ^FAIL
(Or manually digging through miles of logs.)
Thanks!
Nathan
Re: Makefile.svn: a dumb question
Posted by Nathan Hartman <ha...@gmail.com>.
On Thu, Jan 2, 2020 at 1:03 PM Daniel Shahaf <d....@daniel.shahaf.name> wrote:
>
> Nathan Hartman wrote on Thu, 02 Jan 2020 17:44 +00:00:
> > On Thu, Jan 2, 2020 at 11:35 AM Daniel Shahaf <d....@daniel.shahaf.name> wrote:
> > > Nathan Hartman wrote on Thu, Jan 02, 2020 at 10:45:25 -0500:
> > > > Regarding the one test failure I had (autoprop_tests.py 7 with
> > > > [svn x bdb]), I've had two more since, both with bdb. These are
> > > > intermittent database errors and occur in varying places. (All fsfs
> > > > tests have passed every time.)
> > >
> > > Actually, all three backtraces so far are in sbox.build(), so something like
> > > this might be useful:
> >
> > I'm a bit confused here. Yes, the Python backtraces show it coming from
> > sbox.build but aren't these being instigated by the BDB errors/panics
> > (which are reported as a E160029)?
>
> sbox.build() calls svnadmin, which exits with E160029 (and, apparently,
> SIGABRT), which becomes an uncaught Python exception, which triggers the
> stack trace, which lists sbox.build().
>
> The point is, the errors always happened during sbox.build(), never
> during any other part of the test functions [the ones listed in
> «test_list»], so you should be able to reproduce the errors much more
> quickly by running the test suite with that patch. For example, you
> could run the test suite with the older bdb, establish how many FAILs
> you get per 2000 test functions, and then upgrade bdb and try again.
>
> Makes sense?
Yes, this makes sense now. Thank you for explaining in detail.
I'll try it soon and will post my findings...
Thanks,
Nathan
Re: Makefile.svn: a dumb question
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Nathan Hartman wrote on Thu, 02 Jan 2020 17:44 +00:00:
> On Thu, Jan 2, 2020 at 11:35 AM Daniel Shahaf <d....@daniel.shahaf.name> wrote:
> > Nathan Hartman wrote on Thu, Jan 02, 2020 at 10:45:25 -0500:
> > > Regarding the one test failure I had (autoprop_tests.py 7 with
> > > [svn x bdb]), I've had two more since, both with bdb. These are
> > > intermittent database errors and occur in varying places. (All fsfs
> > > tests have passed every time.)
> >
> > Actually, all three backtraces so far are in sbox.build(), so something like
> > this might be useful:
>
> I'm a bit confused here. Yes, the Python backtraces show it coming from
> sbox.build but aren't these being instigated by the BDB errors/panics
> (which are reported as a E160029)?
sbox.build() calls svnadmin, which exits with E160029 (and, apparently,
SIGABRT), which becomes an uncaught Python exception, which triggers the
stack trace, which lists sbox.build().
The point is, the errors always happened during sbox.build(), never
during any other part of the test functions [the ones listed in
«test_list»], so you should be able to reproduce the errors much more
quickly by running the test suite with that patch. For example, you
could run the test suite with the older bdb, establish how many FAILs
you get per 2000 test functions, and then upgrade bdb and try again.
Makes sense?
Re: Makefile.svn: a dumb question
Posted by Nathan Hartman <ha...@gmail.com>.
On Thu, Jan 2, 2020 at 11:35 AM Daniel Shahaf <d....@daniel.shahaf.name>
wrote:
> Nathan Hartman wrote on Thu, Jan 02, 2020 at 10:45:25 -0500:
> > Regarding the one test failure I had (autoprop_tests.py 7 with
> > [svn x bdb]), I've had two more since, both with bdb. These are
> > intermittent database errors and occur in varying places. (All fsfs
> > tests have passed every time.)
>
> Actually, all three backtraces so far are in sbox.build(), so something
> like
> this might be useful:
>
> [[[
> Index: subversion/tests/cmdline/basic_tests.py
> ===================================================================
> --- subversion/tests/cmdline/basic_tests.py (revision 1871981)
> +++ subversion/tests/cmdline/basic_tests.py (working copy)
> @@ -3319,6 +3319,7 @@
> null_prop_update_last_changed_revision,
> filtered_ls_top_level_path,
> ]
> +test_list = [ None ] + [ lambda sbox: sbox.build() ] * 2000
>
> if __name__ == '__main__':
> svntest.main.run_tests(test_list)
> ]]]
>
> … then pass «TESTS="subversion/tests/cmdline/basic_tests.py"» to make.
>
> (I didn't test that patch, so it might complain about a missing __doc__
> attribute, but you get the idea.)
>
> Cheers,
>
> Daniel
> (And you can use «operator.methodcaller('build')» to squeeze a few more
> cycles there)
I'm a bit confused here. Yes, the Python backtraces show it coming from
sbox.build but aren't these being instigated by the BDB errors/panics
(which are reported as a E160029)?
Thanks,
Nathan
Re: Makefile.svn: a dumb question
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Nathan Hartman wrote on Thu, Jan 02, 2020 at 10:45:25 -0500:
> Regarding the one test failure I had (autoprop_tests.py 7 with
> [svn x bdb]), I've had two more since, both with bdb. These are
> intermittent database errors and occur in varying places. (All fsfs
> tests have passed every time.)
Actually, all three backtraces so far are in sbox.build(), so something like
this might be useful:
[[[
Index: subversion/tests/cmdline/basic_tests.py
===================================================================
--- subversion/tests/cmdline/basic_tests.py (revision 1871981)
+++ subversion/tests/cmdline/basic_tests.py (working copy)
@@ -3319,6 +3319,7 @@
null_prop_update_last_changed_revision,
filtered_ls_top_level_path,
]
+test_list = [ None ] + [ lambda sbox: sbox.build() ] * 2000
if __name__ == '__main__':
svntest.main.run_tests(test_list)
]]]
… then pass «TESTS="subversion/tests/cmdline/basic_tests.py"» to make.
(I didn't test that patch, so it might complain about a missing __doc__
attribute, but you get the idea.)
Cheers,
Daniel
(And you can use «operator.methodcaller('build')» to squeeze a few more cycles there)
Re: Makefile.svn: a dumb question
Posted by Stefan Sperling <st...@elego.de>.
On Thu, Jan 02, 2020 at 10:45:25AM -0500, Nathan Hartman wrote:
> Before investigating too much further, I see that Makefile.svn is
> downloading an antique bdb 4.7.25. From the Subversion 1.13.0-rc1
> signing emails [1], I see that Brane runs his tests with the newest,
> 18.1.32. So I'll try that and see if the failures go away (assuming I
> succeed to actually build it -- that's a big major version jump).
If I'm not mistaken, newer BDB versions don't allow a non-threaded
build of BDB. Which is why this wasn't updated.
Re: Makefile.svn: a dumb question
Posted by Nathan Hartman <ha...@gmail.com>.
On Sat, Dec 28, 2019 at 12:13 PM Daniel Shahaf <d....@daniel.shahaf.name> wrote:
> Nathan Hartman wrote on Fri, Dec 27, 2019 at 15:39:10 -0500:
> > On Fri, Dec 27, 2019 at 12:41 AM Daniel Shahaf <d....@daniel.shahaf.name> wrote:
> > > Forgot to say this earlier, but you might try running a threaded svnserve. In
> > > plain trunk that's «make svnserveautocheck THREADED=1»; I don't know how to do
> > > that in stsp's distro.
> >
> > I'll give it a try. I have to study how the makefile invokes the
> > regression tests.
> >
> > There is a variable THREADING in the makefile; it defaults to yes and
> > activates threading and thread-safety stuff in apr, gettext, ruby, and
> > sqlite. It has no effect on the Subversion build or tests.
>
> To be clear, I was referring to the variable THREADED in Subversion's Makefile,
> not to anything in stsp's distro. Perhaps this? —
>
> Index: tools/dev/unix-build/Makefile.svn
> ===================================================================
> --- tools/dev/unix-build/Makefile.svn (revision 1871981)
> +++ tools/dev/unix-build/Makefile.svn (working copy)
> @@ -2165,6 +2165,7 @@
> env LD_LIBRARY_PATH=$(LD_LIBRARY_PATH) $(LIB_PTHREAD_HACK) \
> env MAKEFLAGS= make check PARALLEL=$(PARALLEL) CLEANUP=$(CLEANUP) \
> EXCLUSIVE_WC_LOCKS=$(EXCLUSIVE_WC_LOCKS) \
> + THREADED=$(THREADED) \
> SVN_BIN_DIR=$(SVN_PREFIX)/bin \
> MEMCACHED_SERVER=$(MEMCACHED_SERVER) $1 FS_TYPE=$$fs; \
> for log in tests.log fails.log; do \
>
> (If it works for you, feel free to commit it, but note the comment at the top
> of the file.)
Daniel, as you suggested previously (w/patch above), I added
"THREADED=$(THREADED)" to pass-through THREADED from stsp's
Makefile.svn to Subversion's Makefile (which in turn passes it to
svnserveautocheck.sh, which then invokes svnserve with -T). I think
that's the correct behavior and it should be committed. Hopefully
it will help us get better test coverage with and without threading.
(I'll commit it a little later today.)
Regarding the one test failure I had (autoprop_tests.py 7 with
[svn x bdb]), I've had two more since, both with bdb. These are
intermittent database errors and occur in varying places. (All fsfs
tests have passed every time.)
Before investigating too much further, I see that Makefile.svn is
downloading an antique bdb 4.7.25. From the Subversion 1.13.0-rc1
signing emails [1], I see that Brane runs his tests with the newest,
18.1.32. So I'll try that and see if the failures go away (assuming I
succeed to actually build it -- that's a big major version jump).
[1] https://s.apache.org/q75t8
Just for completeness (because I know I'll lose the logs later), this
is a list of the bdb test failures I've had thus far:
* autoprop_tests.py 7 with [svn x bdb] (mentioned previously)
* prop_tests.py 3 with [local x bdb]
* merge_tree_conflict_tests.py 3 with [svn x bdb]
Details of the latter two are below:
**********************************************************************
[[[
Begin test: local x bdb
...
[098/123] prop_tests.py..................................................FAILURE
...
At least one test FAILED, checking
/home/nate/ramdrive/svndev/svn-trunk/tests.log
FAIL: prop_tests.py 3: receive properties via update
Summary of test results:
2496 tests PASSED
157 tests SKIPPED
94 tests XFAILED (17 WORK-IN-PROGRESS)
1 test FAILED
Python version: 3.7.5.
SUMMARY: Some tests failed
]]]
From fails.log.svn-check-local-bdb:
[[[
W: * Dumped revision 0.
subversion/svnadmin/svnadmin.c:1475,
subversion/libsvn_repos/dump.c:2175,
subversion/libsvn_delta/path_driver.c:190,
subversion/libsvn_delta/path_driver.c:328,
subversion/libsvn_repos/replay.c:597,
subversion/libsvn_repos/dump.c:1714,
subversion/libsvn_repos/dump.c:1538,
subversion/libsvn_subr/stream.c:194,
subversion/libsvn_fs_base/reps-strings.c:981,
subversion/libsvn_fs_base/reps-strings.c:873,
subversion/libsvn_fs_base/reps-strings.c:477,
subversion/libsvn_fs_base/bdb/strings-table.c:208,
subversion/libsvn_fs_base/bdb/strings-table.c:96,
subversion/libsvn_fs_base/bdb/bdb-err.c:85,
subversion/libsvn_fs_base/bdb/bdb-err.c:79: (apr_err=SVN_ERR_FS_BERKELEY_DB)
svnadmin: E160029: Berkeley DB error for filesystem
'svn-test-work/local_tmp/repos/db' while creating cursor for reading a
string:
DB_RUNRECOVERY: Fatal error, run database recovery
subversion/libsvn_fs_base/bdb/env.c:230: (apr_err=SVN_ERR_FS_BERKELEY_DB)
svnadmin: E160029: bdb: PANIC: fatal region error detected; run recovery
W: CMD: /home/nate/ramdrive/svndev/prefix/svn-trunk/bin/svnadmin dump
svn-test-work/local_tmp/repos terminated by signal 6
W: CWD: /home/nate/ramdrive/svndev/svn-trunk/subversion/tests/cmdline
W: EXCEPTION: SVNProcessTerminatedBySignal
Traceback (most recent call last):
File "/home/nate/ramdrive/svndev/svn-trunk/subversion/tests/cmdline/svntest/main.py",
line 1931, in run
rc = self.pred.run(sandbox)
File "/home/nate/ramdrive/svndev/svn-trunk/subversion/tests/cmdline/svntest/testcase.py",
line 178, in run
result = self.func(sandbox)
File "/home/nate/ramdrive/svndev/svn-trunk/subversion/tests/cmdline/prop_tests.py",
line 147, in update_props
sbox.build()
File "/home/nate/ramdrive/svndev/svn-trunk/subversion/tests/cmdline/svntest/sandbox.py",
line 164, in build
minor_version, tree)
File "/home/nate/ramdrive/svndev/svn-trunk/subversion/tests/cmdline/svntest/actions.py",
line 1994, in make_repo_and_wc
guarantee_greek_repository(sbox.repo_dir, minor_version)
File "/home/nate/ramdrive/svndev/svn-trunk/subversion/tests/cmdline/svntest/actions.py",
line 193, in guarantee_greek_repository
_guarantee_repos(path, main.pristine_greek_repos_dir, minor_version)
File "/home/nate/ramdrive/svndev/svn-trunk/subversion/tests/cmdline/svntest/actions.py",
line 178, in _guarantee_repos
failed = main.copy_repos(repos_dir, path, 1, 1, minor_version)
File "/home/nate/ramdrive/svndev/svn-trunk/subversion/tests/cmdline/svntest/main.py",
line 1246, in copy_repos
dump_stdout, dump_stderr, dump_exit_code = wait_on_pipe(dump_kid, True)
File "/home/nate/ramdrive/svndev/svn-trunk/subversion/tests/cmdline/svntest/main.py",
line 557, in wait_on_pipe
raise SVNProcessTerminatedBySignal
svntest.main.SVNProcessTerminatedBySignal
FAIL: prop_tests.py 3: receive properties via update
]]]
**********************************************************************
[[[
Begin test: svn x bdb
...
[091/123] merge_tree_conflict_tests.py...................................FAILURE
...
At least one test FAILED, checking
/home/nate/ramdrive/svndev/svn-trunk/tests.log
FAIL: merge_tree_conflict_tests.py 3: merge on deleted directory in target
Summary of test results:
2531 tests PASSED
119 tests SKIPPED
97 tests XFAILED (17 WORK-IN-PROGRESS)
1 test FAILED
Python version: 3.7.5.
SUMMARY: Some tests failed
]]]
From fails.log.svn-check-svn-bdb:
[[[
W: * Dumped revision 0.
subversion/svnadmin/svnadmin.c:1475,
subversion/libsvn_repos/dump.c:2175,
subversion/libsvn_delta/path_driver.c:190,
subversion/libsvn_delta/path_driver.c:328,
subversion/libsvn_repos/replay.c:534,
subversion/libsvn_fs/fs-loader.c:1223,
subversion/libsvn_fs_base/tree.c:1193,
subversion/libsvn_fs_base/tree.c:1165,
subversion/libsvn_fs_base/tree.c:1026,
subversion/libsvn_fs_base/trail.c:218,
subversion/libsvn_fs_base/bdb/bdb-err.c:85,
subversion/libsvn_fs_base/bdb/bdb-err.c:79: (apr_err=SVN_ERR_FS_BERKELEY_DB)
svnadmin: E160029: Berkeley DB error for filesystem
'svn-test-work/local_tmp/repos/db' while checkpointing after Berkeley
DB transaction:
DB_RUNRECOVERY: Fatal error, run database recovery
subversion/libsvn_fs_base/bdb/env.c:230: (apr_err=SVN_ERR_FS_BERKELEY_DB)
svnadmin: E160029: bdb: PANIC: fatal region error detected; run recovery
W: CMD: /home/nate/ramdrive/svndev/prefix/svn-trunk/bin/svnadmin dump
svn-test-work/local_tmp/repos terminated by signal 6
W: CWD: /home/nate/ramdrive/svndev/svn-trunk/subversion/tests/cmdline
W: EXCEPTION: SVNProcessTerminatedBySignal
Traceback (most recent call last):
File "/home/nate/ramdrive/svndev/svn-trunk/subversion/tests/cmdline/svntest/main.py",
line 1931, in run
rc = self.pred.run(sandbox)
File "/home/nate/ramdrive/svndev/svn-trunk/subversion/tests/cmdline/svntest/testcase.py",
line 258, in run
return self._delegate.run(sandbox)
File "/home/nate/ramdrive/svndev/svn-trunk/subversion/tests/cmdline/svntest/testcase.py",
line 178, in run
result = self.func(sandbox)
File "/home/nate/ramdrive/svndev/svn-trunk/subversion/tests/cmdline/merge_tree_conflict_tests.py",
line 266, in merge_tree_deleted_in_target
sbox.build()
File "/home/nate/ramdrive/svndev/svn-trunk/subversion/tests/cmdline/svntest/sandbox.py",
line 164, in build
minor_version, tree)
File "/home/nate/ramdrive/svndev/svn-trunk/subversion/tests/cmdline/svntest/actions.py",
line 1994, in make_repo_and_wc
guarantee_greek_repository(sbox.repo_dir, minor_version)
File "/home/nate/ramdrive/svndev/svn-trunk/subversion/tests/cmdline/svntest/actions.py",
line 193, in guarantee_greek_repository
_guarantee_repos(path, main.pristine_greek_repos_dir, minor_version)
File "/home/nate/ramdrive/svndev/svn-trunk/subversion/tests/cmdline/svntest/actions.py",
line 178, in _guarantee_repos
failed = main.copy_repos(repos_dir, path, 1, 1, minor_version)
File "/home/nate/ramdrive/svndev/svn-trunk/subversion/tests/cmdline/svntest/main.py",
line 1246, in copy_repos
dump_stdout, dump_stderr, dump_exit_code = wait_on_pipe(dump_kid, True)
File "/home/nate/ramdrive/svndev/svn-trunk/subversion/tests/cmdline/svntest/main.py",
line 557, in wait_on_pipe
raise SVNProcessTerminatedBySignal
svntest.main.SVNProcessTerminatedBySignal
FAIL: merge_tree_conflict_tests.py 3: merge on deleted directory in target
]]]
**********************************************************************
Happy New Year,
Nathan
Re: Makefile.svn: a dumb question
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Nathan Hartman wrote on Fri, Dec 27, 2019 at 15:39:10 -0500:
> On Fri, Dec 27, 2019 at 12:41 AM Daniel Shahaf <d....@daniel.shahaf.name> wrote:
> > Nathan Hartman wrote on Thu, Dec 26, 2019 at 17:02:21 -0500:
> > > (If you're wondering about /dev/sdb1, it appears to be a regular disk,
> > > not a ramdrive, because this is a virtual machine and the ramdrive is
> > > a disk image in RAM on the host. This allows it to persist through
> > > reboots of the guest, moved to other guests, etc).
> >
> > But if the guest's kernel sees an ordinary block device, it'll still try to
> > sync(2) it, won't it? I wonder if you'll see any benefit from eatmydata(1).
>
> Yes, it's kind of dumb to sync to a ramdisk. I'll play around with
> eatmydata and see how much of a difference it makes in execution time.
> Maybe I'll use that when I'm in a hurry. The full test suite with all
> RA and backends took nearly 2.5 hours. I didn't know about eatmydata.
> Thanks for mentioning it.
For reference, on my desktop it takes 56s to build and 581s to run a single
svnserveautocheck. It's a non-virtualized maintainer mode build.
> > > I don't know why the test failed before. Could be timing or something
> > > else happening on the computer? As I continue experimenting, we'll see
> > > if it fails again... I'll keep everyone posted.
> >
> > Forgot to say this earlier, but you might try running a threaded svnserve. In
> > plain trunk that's «make svnserveautocheck THREADED=1»; I don't know how to do
> > that in stsp's distro.
>
> I'll give it a try. I have to study how the makefile invokes the
> regression tests.
>
> There is a variable THREADING in the makefile; it defaults to yes and
> activates threading and thread-safety stuff in apr, gettext, ruby, and
> sqlite. It has no effect on the Subversion build or tests.
To be clear, I was referring to the variable THREADED in Subversion's Makefile,
not to anything in stsp's distro. Perhaps this? —
Index: tools/dev/unix-build/Makefile.svn
===================================================================
--- tools/dev/unix-build/Makefile.svn (revision 1871981)
+++ tools/dev/unix-build/Makefile.svn (working copy)
@@ -2165,6 +2165,7 @@
env LD_LIBRARY_PATH=$(LD_LIBRARY_PATH) $(LIB_PTHREAD_HACK) \
env MAKEFLAGS= make check PARALLEL=$(PARALLEL) CLEANUP=$(CLEANUP) \
EXCLUSIVE_WC_LOCKS=$(EXCLUSIVE_WC_LOCKS) \
+ THREADED=$(THREADED) \
SVN_BIN_DIR=$(SVN_PREFIX)/bin \
MEMCACHED_SERVER=$(MEMCACHED_SERVER) $1 FS_TYPE=$$fs; \
for log in tests.log fails.log; do \
(If it works for you, feel free to commit it, but note the comment at the top
of the file.)
Cheers,
Daniel
Re: Makefile.svn: a dumb question
Posted by Stefan Sperling <st...@elego.de>.
On Fri, Dec 27, 2019 at 03:39:10PM -0500, Nathan Hartman wrote:
> There is a variable THREADING in the makefile; it defaults to yes and
> activates threading and thread-safety stuff in apr, gettext, ruby, and
> sqlite. It has no effect on the Subversion build or tests.
The svn-bb-openbsd buildbot compiles without support for threading.
This is to ensure that we don't introduce bugs with non-threaded APR
which is a rather uncommon, but still supported, configuration.
Re: Makefile.svn: a dumb question
Posted by Nathan Hartman <ha...@gmail.com>.
On Fri, Dec 27, 2019 at 12:41 AM Daniel Shahaf <d....@daniel.shahaf.name> wrote:
> Nathan Hartman wrote on Thu, Dec 26, 2019 at 17:02:21 -0500:
> > (If you're wondering about /dev/sdb1, it appears to be a regular disk,
> > not a ramdrive, because this is a virtual machine and the ramdrive is
> > a disk image in RAM on the host. This allows it to persist through
> > reboots of the guest, moved to other guests, etc).
>
> But if the guest's kernel sees an ordinary block device, it'll still try to
> sync(2) it, won't it? I wonder if you'll see any benefit from eatmydata(1).
Yes, it's kind of dumb to sync to a ramdisk. I'll play around with
eatmydata and see how much of a difference it makes in execution time.
Maybe I'll use that when I'm in a hurry. The full test suite with all
RA and backends took nearly 2.5 hours. I didn't know about eatmydata.
Thanks for mentioning it.
> > I don't know why the test failed before. Could be timing or something
> > else happening on the computer? As I continue experimenting, we'll see
> > if it fails again... I'll keep everyone posted.
>
> Forgot to say this earlier, but you might try running a threaded svnserve. In
> plain trunk that's «make svnserveautocheck THREADED=1»; I don't know how to do
> that in stsp's distro.
I'll give it a try. I have to study how the makefile invokes the
regression tests.
There is a variable THREADING in the makefile; it defaults to yes and
activates threading and thread-safety stuff in apr, gettext, ruby, and
sqlite. It has no effect on the Subversion build or tests.
Nathan
Re: Makefile.svn: a dumb question
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Nathan Hartman wrote on Thu, Dec 26, 2019 at 17:02:21 -0500:
> On Thu, Dec 26, 2019 at 12:04 PM Daniel Shahaf <d....@daniel.shahaf.name> wrote:
> > > Here are the contents of fails.log.svn-check-svn-bdb -- could be some
> > > kind of fluke? I just started another full test run. Let's see if it
> > > repeats:
> >
> > It's _possible_ that some dependency upgrade introduced a heisenbug, but
> > Occam's razor says it's more likely to be something in your setup. I guess
> > svn-test-work is on a ramdisk, so it could be its mount options.
>
> Hmmm. I reran the tests (same sources, with r1866425-rework-patch
> applied). This time all the tests passed, including autoprop_tests.py
> #7 for svnserve x bdb.
The test failure was in the bowls of sbox.build(), in the part that's run for
the vast majority of test functions. It's fairly likely that it had nothing to
do with that particular test function and test file.
> Both times, I ran everything under a ramdrive, which is mounted with
> rw,relatime:
>
> $ cat /proc/mounts | grep ramdrive
> /dev/sdb1 /home/nate/ramdrive ext4 rw,relatime 0 0
>
> (If you're wondering about /dev/sdb1, it appears to be a regular disk,
> not a ramdrive, because this is a virtual machine and the ramdrive is
> a disk image in RAM on the host. This allows it to persist through
> reboots of the guest, moved to other guests, etc).
But if the guest's kernel sees an ordinary block device, it'll still try to
sync(2) it, won't it? I wonder if you'll see any benefit from eatmydata(1).
> I don't know why the test failed before. Could be timing or something
> else happening on the computer? As I continue experimenting, we'll see
> if it fails again... I'll keep everyone posted.
Forgot to say this earlier, but you might try running a threaded svnserve. In
plain trunk that's «make svnserveautocheck THREADED=1»; I don't know how to do
that in stsp's distro.
Cheers,
Daniel
Re: Makefile.svn: a dumb question
Posted by Nathan Hartman <ha...@gmail.com>.
On Thu, Dec 26, 2019 at 12:04 PM Daniel Shahaf <d....@daniel.shahaf.name> wrote:
> > Here are the contents of fails.log.svn-check-svn-bdb -- could be some
> > kind of fluke? I just started another full test run. Let's see if it
> > repeats:
>
> It's _possible_ that some dependency upgrade introduced a heisenbug, but
> Occam's razor says it's more likely to be something in your setup. I guess
> svn-test-work is on a ramdisk, so it could be its mount options.
Hmmm. I reran the tests (same sources, with r1866425-rework-patch
applied). This time all the tests passed, including autoprop_tests.py
#7 for svnserve x bdb.
Both times, I ran everything under a ramdrive, which is mounted with
rw,relatime:
$ cat /proc/mounts | grep ramdrive
/dev/sdb1 /home/nate/ramdrive ext4 rw,relatime 0 0
(If you're wondering about /dev/sdb1, it appears to be a regular disk,
not a ramdrive, because this is a virtual machine and the ramdrive is
a disk image in RAM on the host. This allows it to persist through
reboots of the guest, moved to other guests, etc).
I don't know why the test failed before. Could be timing or something
else happening on the computer? As I continue experimenting, we'll see
if it fails again... I'll keep everyone posted.
Also, I'll try the default-jdk-headless and junit4 packages and let
you know how that works out...
Thanks for your help...
Nathan
Re: Makefile.svn: a dumb question
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Nathan Hartman wrote on Thu, 26 Dec 2019 16:48 +00:00:
> One more question: Does anyone know which package(s) to install on
> Debian to be able to run the JavaHL tests?
Probably these:
% apt-cache showsrc subversion | grep Build-Depends | vipe
default-jdk-headless (>= 2:1.8) [!hurd-i386 !hppa !sparc] <!pkg.subversion.nojava>
junit4 [!hurd-i386 !hppa !sparc] <!pkg.subversion.nojava>
%
> Here are the contents of fails.log.svn-check-svn-bdb -- could be some
> kind of fluke? I just started another full test run. Let's see if it
> repeats:
It's _possible_ that some dependency upgrade introduced a heisenbug, but
Occam's razor says it's more likely to be something in your setup. I guess
svn-test-work is on a ramdisk, so it could be its mount options.
Cheers,
Daniel
Re: Makefile.svn: a dumb question
Posted by Nathan Hartman <ha...@gmail.com>.
On Thu, Dec 26, 2019 at 6:00 AM Stefan Sperling <st...@elego.de> wrote:
> On Thu, Dec 26, 2019 at 02:37:03AM +0000, Daniel Shahaf wrote:
> > It would be nice to find a way for you to share your changes without breaking
> > the bot. Could you talk to stsp about this?
>
> Yes I can help here. Please share your patches and I will integrate them.
> I kept serf-old around to be able to build 1.5 but at this point it's fine
> for me to lose the ability to build it.
I'm attaching 3 patches:
* patch-1-serf-only.txt - Only update to Serf 1.4.x.
* patch-2-sasl-only.txt - Only update to Cyrus SASL 2.1.27.
* full-patch.txt - Contains both of the above + remove all Serf-Old
stuff for svn 1.5.
You can choose to apply changes in several commits by applying them in
that order, or, you can apply just full-patch.txt to get all the
changes.
Thanks for helping with fails.log.* and pointing out to grep the
binding test log files per the svn-bb-openbsd buildbot scripts. That's
very helpful. :-)
One more question: Does anyone know which package(s) to install on
Debian to be able to run the JavaHL tests?
Regarding the svnserve x bdb test failure:
> > Observations from running the regression tests:
> >
> > (1) I get one test failure in [svn x bdb]:
> > FAIL: autoprop_tests.py 7: import: config=no, commandline=none
> >
> > This test passes for all other RA x backend combinations.
>
> With trunk on Linux:
>
> % make svnserveautocheck FS_TYPE=bdb CLEANUP=1 TESTS="subversion/tests/cmdline/autoprop_tests.py"
> ⋮
> SUMMARY: All tests successful
> %
>
> What was the error (in the .log file)?
Here are the contents of fails.log.svn-check-svn-bdb -- could be some
kind of fluke? I just started another full test run. Let's see if it
repeats:
[[[
W: * Dumped revision 0.
subversion/svnadmin/svnadmin.c:1475,
subversion/libsvn_repos/dump.c:2175,
subversion/libsvn_delta/path_driver.c:190,
subversion/libsvn_delta/path_driver.c:328,
subversion/libsvn_repos/replay.c:534,
subversion/libsvn_fs/fs-loader.c:1223,
subversion/libsvn_fs_base/tree.c:1193,
subversion/libsvn_fs_base/tree.c:1165,
subversion/libsvn_fs_base/tree.c:1026,
subversion/libsvn_fs_base/trail.c:218,
subversion/libsvn_fs_base/trail.c:159,
subversion/libsvn_fs_base/bdb/bdb-err.c:85,
subversion/libsvn_fs_base/bdb/bdb-err.c:79: (apr_err=SVN_ERR_FS_BERKELEY_DB)
svnadmin: E160029: Berkeley DB error for filesystem
'svn-test-work/local_tmp/repos/db' while committing Berkeley DB
transaction:
DB_RUNRECOVERY: Fatal error, run database recovery
subversion/libsvn_fs_base/bdb/env.c:230: (apr_err=SVN_ERR_FS_BERKELEY_DB)
svnadmin: E160029: bdb: PANIC: fatal region error detected; run recovery
W: CMD: /home/nate/ramdrive/svndev/prefix/svn-trunk/bin/svnadmin dump
svn-test-work/local_tmp/repos terminated by signal 6
W: CWD: /home/nate/ramdrive/svndev/svn-trunk/subversion/tests/cmdline
W: EXCEPTION: SVNProcessTerminatedBySignal
Traceback (most recent call last):
File "/home/nate/ramdrive/svndev/svn-trunk/subversion/tests/cmdline/svntest/main.py",
line 1931, in run
rc = self.pred.run(sandbox)
File "/home/nate/ramdrive/svndev/svn-trunk/subversion/tests/cmdline/svntest/testcase.py",
line 178, in run
result = self.func(sandbox)
File "/home/nate/ramdrive/svndev/svn-trunk/subversion/tests/cmdline/autoprop_tests.py",
line 245, in autoprops_imp_no_none
autoprops_test(sbox, 'import', 0, 0, '')
File "/home/nate/ramdrive/svndev/svn-trunk/subversion/tests/cmdline/autoprop_tests.py",
line 101, in autoprops_test
sbox.build()
File "/home/nate/ramdrive/svndev/svn-trunk/subversion/tests/cmdline/svntest/sandbox.py",
line 164, in build
minor_version, tree)
File "/home/nate/ramdrive/svndev/svn-trunk/subversion/tests/cmdline/svntest/actions.py",
line 1994, in make_repo_and_wc
guarantee_greek_repository(sbox.repo_dir, minor_version)
File "/home/nate/ramdrive/svndev/svn-trunk/subversion/tests/cmdline/svntest/actions.py",
line 193, in guarantee_greek_repository
_guarantee_repos(path, main.pristine_greek_repos_dir, minor_version)
File "/home/nate/ramdrive/svndev/svn-trunk/subversion/tests/cmdline/svntest/actions.py",
line 178, in _guarantee_repos
failed = main.copy_repos(repos_dir, path, 1, 1, minor_version)
File "/home/nate/ramdrive/svndev/svn-trunk/subversion/tests/cmdline/svntest/main.py",
line 1246, in copy_repos
dump_stdout, dump_stderr, dump_exit_code = wait_on_pipe(dump_kid, True)
File "/home/nate/ramdrive/svndev/svn-trunk/subversion/tests/cmdline/svntest/main.py",
line 557, in wait_on_pipe
raise SVNProcessTerminatedBySignal
svntest.main.SVNProcessTerminatedBySignal
FAIL: autoprop_tests.py 7: import: config=no, commandline=none
]]]
Thanks,
Nathan
Re: Makefile.svn: a dumb question
Posted by Stefan Sperling <st...@elego.de>.
On Thu, Dec 26, 2019 at 02:37:03AM +0000, Daniel Shahaf wrote:
> Nathan Hartman wrote on Wed, Dec 25, 2019 at 12:07:35 -0500:
> > On Wed, Dec 25, 2019 at 1:38 AM Yasuhito FUTATSUKI <fu...@poem.co.jp> wrote:
> > >
> > > On 2019/12/25 6:38, Nathan Hartman wrote:
> > > > When running the regression test suite via the 'svn-check' target of
> > > > tools/dev/unix-build/Makefile.svn, is there a convenient way to see a
> > > > "All tests successful"-type summary at the very end?
> > > >
> > > > That is to say, is there a better way than what I'm doing now,
> > > > which is:
> > > >
> > > > $ cat tests.log.* | grep ^FAIL
> > >
> > > It isn't an answer for your question, but this can miss 'XPASS'.
> >
> > Thank you. Yes, you are right.
> >
> > I ran it again, redirecting stderr and stdout to a file, and that
> > generates much less output (around 2000 lines). But if someone has a
> > better way, I'd love to hear about it.
>
> For starters, you can use the fails.log files. They're generated by
> build/run_tests.py after tests.log gets fully written (not during the run), and
> they aren't removed when a test run starts (so beware of them remaining around
> after you've already fixed a bug), but if they exist at all, they contain only
> FAILs and XPASSes. If you're just looking for a quick "Did any test fail?"
> bit, you can just check whether any fails.log.* file exists.
Yes that is exactly what I do: Look for fails.log.*
> I don't know of an easy answer to your question for bindings tests. Does the
> svn-check target exit non-zero when any test has failed? If it did, that would
> at least handle the common case of "All tests passed".
>
> stsp may know more.
Check the svn-bb-openbsd buildbot scrips and you will find the answer :)
(It greps the binding test log files.)
> > To make successfully on Debian Buster, because of OpenSSL 1.1.1d, I
> > modified Makefile.svn to use Serf 1.4.x (from branches as there is no
> > 1.4.x release yet) and Cyrus SASL 2.1.27. Also I removed all the
> > serf-old targets which are applicable to svn 1.5 and were breaking the
> > build for me, thanks again to OpenSSL. I didn't commit my changes
> > because that will probably break the OpenBSD buildbot.
>
> It would be nice to find a way for you to share your changes without breaking
> the bot. Could you talk to stsp about this?
Yes I can help here. Please share your patches and I will integrate them.
I kept serf-old around to be able to build 1.5 but at this point it's fine
for me to lose the ability to build it.
Re: Makefile.svn: a dumb question
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Nathan Hartman wrote on Wed, Dec 25, 2019 at 12:07:35 -0500:
> On Wed, Dec 25, 2019 at 1:38 AM Yasuhito FUTATSUKI <fu...@poem.co.jp> wrote:
> >
> > On 2019/12/25 6:38, Nathan Hartman wrote:
> > > When running the regression test suite via the 'svn-check' target of
> > > tools/dev/unix-build/Makefile.svn, is there a convenient way to see a
> > > "All tests successful"-type summary at the very end?
> > >
> > > That is to say, is there a better way than what I'm doing now,
> > > which is:
> > >
> > > $ cat tests.log.* | grep ^FAIL
> >
> > It isn't an answer for your question, but this can miss 'XPASS'.
>
> Thank you. Yes, you are right.
>
> I ran it again, redirecting stderr and stdout to a file, and that
> generates much less output (around 2000 lines). But if someone has a
> better way, I'd love to hear about it.
For starters, you can use the fails.log files. They're generated by
build/run_tests.py after tests.log gets fully written (not during the run), and
they aren't removed when a test run starts (so beware of them remaining around
after you've already fixed a bug), but if they exist at all, they contain only
FAILs and XPASSes. If you're just looking for a quick "Did any test fail?"
bit, you can just check whether any fails.log.* file exists.
I don't know of an easy answer to your question for bindings tests. Does the
svn-check target exit non-zero when any test has failed? If it did, that would
at least handle the common case of "All tests passed".
stsp may know more.
> Observations from running the regression tests:
>
> (1) I get one test failure in [svn x bdb]:
> FAIL: autoprop_tests.py 7: import: config=no, commandline=none
>
> This test passes for all other RA x backend combinations.
With trunk on Linux:
% make svnserveautocheck FS_TYPE=bdb CLEANUP=1 TESTS="subversion/tests/cmdline/autoprop_tests.py"
⋮
SUMMARY: All tests successful
%
What was the error (in the .log file)?
> For this test run, I ran the test on trunk@1871942 with Sergey's
> patch "Rework of r1866425 ('Last-Modified' header)" [1] applied. (I
> doubt that should affect the autoprop test that failed above? I'll
> have to run it again without the patch to find out.)
That patch shouldn't affect the ra_svn/bdb behaviour, unless you run
davautocheck and svnserveautocheck in parallel on the same svn-test-work
directory.
> Tested: [bdb | fsfs] x [ra_local | ra_svn | ra_serf]
> swig bindings
>
> Platform: Linux 4.19.0-6-rt-amd64 x86_64
>
> Dependencies:
> bdb: 4.7.25
> GNU-iconv: 1.15
> apr: 1.5.2
> apr-util: 1.5.4
> httpd: 2.4.37
> serf: 1.4.x
> cyrus-sasl: 2.1.27
> sqlite: 3160200
> lz4: 1.7.5
> libssl: OpenSSL 1.1.1d 10 Sep 2019
> swig: 3.0.12
> python: 3.7.5
> perl: 5.28.1
> ruby: 2.4.4
:-)
> To make successfully on Debian Buster, because of OpenSSL 1.1.1d, I
> modified Makefile.svn to use Serf 1.4.x (from branches as there is no
> 1.4.x release yet) and Cyrus SASL 2.1.27. Also I removed all the
> serf-old targets which are applicable to svn 1.5 and were breaking the
> build for me, thanks again to OpenSSL. I didn't commit my changes
> because that will probably break the OpenBSD buildbot.
It would be nice to find a way for you to share your changes without breaking
the bot. Could you talk to stsp about this?
> Also it failed on building the perl bindings with "Only one of PREFIX
> or INSTALL_BASE can be given. Not both." I didn't really know what to
> do about that so I just 'env | grep PERL' and unset the four
> environment variables that showed up (PERL5LIB, PERL_MB_OPT,
> PERL_MM_OPT, and PERL_LOCAL_LIB_ROOT) for the session and that got rid
> of the error.
I guess MB and MM stand for Module::Build and ExtUtils::MakeMaker,
respectively. subversion/bindings/swig/perl/native/Makefile.PL.in uses the
latter. So it sounds like PERL_MM_OPT in the build environment conflicts with
how Makefile invokes subversion/bindings/swig/perl/native/Makefile.PL. I don't
know what the fix is, though.
Cheers,
Daniel
Re: Makefile.svn: a dumb question
Posted by Nathan Hartman <ha...@gmail.com>.
On Wed, Dec 25, 2019 at 1:38 AM Yasuhito FUTATSUKI <fu...@poem.co.jp> wrote:
>
> On 2019/12/25 6:38, Nathan Hartman wrote:
> > When running the regression test suite via the 'svn-check' target of
> > tools/dev/unix-build/Makefile.svn, is there a convenient way to see a
> > "All tests successful"-type summary at the very end?
> >
> > That is to say, is there a better way than what I'm doing now,
> > which is:
> >
> > $ cat tests.log.* | grep ^FAIL
>
> It isn't an answer for your question, but this can miss 'XPASS'.
Thank you. Yes, you are right.
I ran it again, redirecting stderr and stdout to a file, and that
generates much less output (around 2000 lines). But if someone has a
better way, I'd love to hear about it.
Observations from running the regression tests:
(1) I get one test failure in [svn x bdb]:
FAIL: autoprop_tests.py 7: import: config=no, commandline=none
This test passes for all other RA x backend combinations.
(2) In authz_tests.py with Python 3.7.5 I get a DeprecationWarning on
use of the imp module:
[063/123] authz_tests.py./build/run_tests.py:53:
DeprecationWarning: the imp module is deprecated in favour of
importlib; see the module's documentation for alternative uses
import optparse, subprocess, imp, threading, traceback
For this test run, I ran the test on trunk@1871942 with Sergey's
patch "Rework of r1866425 ('Last-Modified' header)" [1] applied. (I
doubt that should affect the autoprop test that failed above? I'll
have to run it again without the patch to find out.) The test
'last_modified_header' in mod_dav_svn_tests.py passes.
Tested: [bdb | fsfs] x [ra_local | ra_svn | ra_serf]
swig bindings
Platform: Linux 4.19.0-6-rt-amd64 x86_64
Dependencies:
bdb: 4.7.25
GNU-iconv: 1.15
apr: 1.5.2
apr-util: 1.5.4
httpd: 2.4.37
serf: 1.4.x
cyrus-sasl: 2.1.27
sqlite: 3160200
lz4: 1.7.5
libssl: OpenSSL 1.1.1d 10 Sep 2019
swig: 3.0.12
python: 3.7.5
perl: 5.28.1
ruby: 2.4.4
To make successfully on Debian Buster, because of OpenSSL 1.1.1d, I
modified Makefile.svn to use Serf 1.4.x (from branches as there is no
1.4.x release yet) and Cyrus SASL 2.1.27. Also I removed all the
serf-old targets which are applicable to svn 1.5 and were breaking the
build for me, thanks again to OpenSSL. I didn't commit my changes
because that will probably break the OpenBSD buildbot.
The Serf 1.3.9 compile error was:
buckets/ssl_buckets.c:250:34: error: dereferencing pointer to incomplete
type 'BIO {aka struct bio_st}'
The Cyrus SASL 2.1.25 compile error was:
otp.c:121:16: error: storage size of 'mdctx' isn't known
EVP_MD_CTX mdctx;
Also it failed on building the perl bindings with "Only one of PREFIX
or INSTALL_BASE can be given. Not both." I didn't really know what to
do about that so I just 'env | grep PERL' and unset the four
environment variables that showed up (PERL5LIB, PERL_MB_OPT,
PERL_MM_OPT, and PERL_LOCAL_LIB_ROOT) for the session and that got rid
of the error.
[1] https://lists.apache.org/thread.html/aff4ab41e87c997fbc90fc79e3240ffcda10fe7f09a1e31bec4af797%40%3Cdev.subversion.apache.org%3E
Cheers,
Nathan
Re: Makefile.svn: a dumb question
Posted by Yasuhito FUTATSUKI <fu...@poem.co.jp>.
On 2019/12/25 6:38, Nathan Hartman wrote:
> When running the regression test suite via the 'svn-check' target of
> tools/dev/unix-build/Makefile.svn, is there a convenient way to see a
> "All tests successful"-type summary at the very end?
>
> That is to say, is there a better way than what I'm doing now,
> which is:
>
> $ cat tests.log.* | grep ^FAIL
It isn't an answer for your question, but this can miss 'XPASS'.
Cheers,
--
Yasuhito FUTATSUKI <fu...@yf.bsdclub.org> / <fu...@poem.co.jp>