Re: Handling non-reproducible test failures (was Re: 1.7.20 release candidates up for testing/signing)
On Fri, Mar 20, 2015 at 10:30 AM, Johan Corveleyn wrote: > On Fri, Mar 20, 2015 at 9:42 AM, Johan Corveleyn wrote: > ... >> Unfortunately, I can't verify the rev >> file, since I don't have it anymore, it has been overwritten by trying >> to reproduce it (g, should remember to backup leftover >> repositories and working copies after a failed test run, before trying >> to reproduce it). Whatever I try now, I can't reproduce it anymore >> :-(. > > I'm wondering if something can be improved in our test suite to help > diagnosis of hard-to-reproduce test failures. When this happens, you > typically wish you could analyse as much data as possible (i.e. the > potentially corrupt repository, working copy, dump file, ... that was > used in the test). > > Currently, I can think of three causes for losing this information: > > 1) You run a series of test runs in sequence from a script > (ra_local, ra_svn, ra_serf), all using the same target directory for > running the tests (R:\test in my case, where R: is a ram drive). If > something fails in ra_svn, but succeeds in ra_serf, your broken test > data is overwritten. > > 2) You don't know in advance that the failure will turn out to be > non-reproducible. You can't believe your eyes, try to run it again to > be sure, and lo and behold, the test succeeds (and the broken test > data is overwritten), and succeeds ever since. > > 3) Your test data is on a RAM drive, and you reboot or something. Or > you copy the data to a fixed disk afterwards, but lose a bit of > information because last-modified timestamps of the copied files are > reset by copying them between disks. > > > For 1, maybe the outer script could detect that ra_svn had a failure, > and stop there (does win-tests.py emit an exit code != 0 if there is a > test failure? That would make it easy. Otherwise the outer script > would have to parse the test summary output)? > > Another option is to let every separate test run (ra_local, ra_svn, > ra_serf) use a distinct target test directory. But if you're running > them on a RAM disk, theoretically you might need three times the > storage (hm, maybe not, because --cleanup ensures that successful test > data is cleaned up, so as long as you don't run the three ways in > parallel, it should be fine). I guess I will do that already, and > adjust my script accordingly. > > > Addressing 2 seems harder. Can the second test execution, on > encountering stale test data, put that data aside instead of > overwriting it? Or maybe every test execution can use a unique naming > pattern (with a timestamp or a pid) so it doesn't overwrite previous > data? Both approaches would leak data from failed test runs of course, > but that's more or less the point. OTOH, you don't know that stale > test data is from a previous failed run, or from a successful run that > did not use --cleanup. > > > And 3, well, I already reboot as little as possible, so this is more > just a point of attention. > > > Maybe addressing all three at the same time could also be: after a > failed test run, automatically zip the test data and copy it to a safe > location (e.g. the user's home dir). > > Thoughts? > FWIW, for the time being (I don't know enough about the test infrastructure to build a more robust solution), I've come up with this quick hack to address point 1, by uniquifying the test directory accross the different test variations: I have a batch script runtest.bat with following contents (note the TESTKEY variable which I use as part of the test-path): [[[ @echo off SETLOCAL SET PATH=%~dp0\dist\bin;%PATH% mkdir R:\temp 2>NUL: SET TMP=R:\temp SET TEMP=R:\temp if "%CONFIG%" == "" SET CONFIG=release SET TESTKEY=%CONFIG%%1%2%3%4%5%6%7%8%9 SET TESTKEY=%TESTKEY::=_% SET TESTKEY=%TESTKEY:/=_% SET TESTKEY=%TESTKEY:\=_% python win-tests.py -c --log-level=DEBUG --%CONFIG% %1 %2 %3 %4 %5 %6 %7 %8 %9 R:\test_%TESTKEY% ENDLOCAL @echo on ]]] And I call this runtest.bat from within another script named alltests.bat: [[[ call runtest -p call runtest -p -u svn://localhost call runtest -p --httpd-dir=C:\Apache24 --httpd-port=1234 --httpd-no-log ]]] Which results in following directories with the test output on my R: (ram-)drive: [[[ R:\>dir /b Temp test_release-p test_release-p--httpd-dirC__Apache24--httpd-port1234--httpd-no-log test_release-p-usvn___localhost ]]] This also helps a bit with point 2 above, because if I retest a failing test, I usually add a -t option to rerun a single test (which would result in another separate test path) A problem might be that I'm making the path too long, and some tests might fail because of that (Windows path length limitations etc). We'll see ... For now it works :-). -- Johan
Re: 1.7.20 release candidates up for testing/signing
On Sun, Mar 22, 2015 at 12:44 PM, Bert Huijben wrote: >> -Original Message- >> From: Johan Corveleyn [mailto:jcor...@gmail.com] >> Sent: zaterdag 21 maart 2015 22:04 >> To: Subversion Development >> Subject: Re: 1.7.20 release candidates up for testing/signing > >> Platform >> >> Windows 7 SP1 (x64) >> Microsoft Visual Studio 2013 >> (after upgrading the VS solution from the generated VS 2010 format to VS 2013 >> format from within the IDE) > > I nominated a patch to handle this for you (and others). See STATUS. > > Not sure how relevant it is, with 1.9 near release, but perhaps we can get it > released anyway. Great, thanks. I'll try to take a look and give that backport nomination a try in the coming week or so. Cheers, -- Johan
RE: 1.7.20 release candidates up for testing/signing
> -Original Message- > From: Johan Corveleyn [mailto:jcor...@gmail.com] > Sent: zaterdag 21 maart 2015 22:04 > To: Subversion Development > Subject: Re: 1.7.20 release candidates up for testing/signing > Platform > > Windows 7 SP1 (x64) > Microsoft Visual Studio 2013 > (after upgrading the VS solution from the generated VS 2010 format to VS 2013 > format from within the IDE) I nominated a patch to handle this for you (and others). See STATUS. Not sure how relevant it is, with 1.9 near release, but perhaps we can get it released anyway. It is possible to generate a single solution and project files that work in VS2010 SP1 and later, VS2012, VS2013 and VS2015 with some MSBuild magic, but I'm not sure if we should go that way. In my experience you have to clean out the intermediate directories when you switch. Bert
Re: Handling non-reproducible test failures (was Re: 1.7.20 release candidates up for testing/signing)
On Fri, Mar 20, 2015 at 8:13 PM, Stefan Fuhrmann wrote: ... > I haven't thought too deeply about it but I think we should > be able to extend the current repo / w/c cleanup infrastructure > to copy the data away upon test failure. Yes, something like that would be a great help. Maybe using an option for providing the "backup-path" (so the default behavior remains the same if you don't provide a backup-path). If we really want to go all the way, there should maybe be some "uniquifying" of the backup path, or of a subdir thereof (so multiple failures of the same test (if you leave different test combinations running all night) don't overwrite each other's backup). -- Johan
Re: 1.7.20 release candidates up for testing/signing
On Wed, Mar 18, 2015 at 3:09 PM, Stefan Sperling wrote: > The 1.7.20 release is now up for testing/signing at > https://dist.apache.org/repos/dist/dev/subversion > Please add your signatures there. > > The anticipated release day is March 31. > > Note that libsvn_subr/mergeinfo-test 6 and 10 may have occasional failures > (segfaults) due to a one-byte read past a string buffer (which cause a crash > on OpenBSD and maybe on other platforms as well). > This is not a regression from 1.7.19 where the problem already existed. Summary --- +1 to release Platform Windows 7 SP1 (x64) Microsoft Visual Studio 2013 (after upgrading the VS solution from the generated VS 2010 format to VS 2013 format from within the IDE) Verified Signature and sha1 for subversion-1.7.20.zip. Contents of subversion-1.7.20.zip are identical to tags/1.7.20, and to branches/1.7.x@1667490 (except for expected differences in svn_version.h and generated files). Tested -- [ Release build ] x [ fsfs ] x [ file | svn | http (serf) | http (neon) ] Results --- All tests pass. For serf I disabled my local AVG Surf-Shield to make it work (issue #4175 - ra_serf crashes on Windows with AVG 2012 Surf-Shield http://subversion.tigris.org/issues/show_bug.cgi?id=4175). Dependencies Httpd 2.4.12 Apr 1.5.1 Apr-Util 1.5.4 OpenSSL 1.0.2 Serf 1.3.8 Neon 0.30.1 SQLite 3.8.8.3 ZLib 1.2.8 Signature - subversion-1.7.20.zip: -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAABCgAGBQJVChmmAAoJELWc5tYBDIqtxPUQAIciUihRne4bRVFtMbIYiOKO 6VMB5Q/HTfeaSF/F8AyEX28HiLS9U/dVJaWPVLDHw8sIscS91Hm+v5h7T0UbyDGE /zoQcjSoLqqFkDuV5EZMknE+f5yDncwXqcXy67pG0usnPdOIK+D6QsxwZfgoP6C6 LUT6qsyDWbV6XGKGNnct1EU1gTTdUjd2ifmf7DWYc3x3Xu/2JVTXkclQc/kurlFT IhKLkDlbQdwnRsGAQQ1k6UtIPcJY8S/WLBeIGZn+2m74ZfEwupM0DR+0YVbH38SM f0UQphLdaQbWQGWFnBb6zBs8GSp1QvVVQPs5dbYsgKJYxSsQSpLb86yo7PWkDpKU rCpT4CATn29497TQRBf+JlIzmaz110+kmfb1imGOFbBTzEOx/XOfEB60Aqk9JjJ3 9QDs6TlW/e3sfJJ/nxzOxs/cK/3QnwMs3Gku8KGDBtErHIi5jXse1sZIrbQ0krmL igOTYckdJIf5ysjXBdFCnPGMNSHFloRcn6m1IZjH7mLEgqyPVRloILja0WoxaPLU uWALZLUB4W0jHTGrXRh/2GgGi60cC/qpKxZYoyFv/5ldtd/w/rLvIxG8bjuO5M1g +uYZZ/7g8UyvkmtenszRna/bbSyRNGyuMNIIf6irUDQtJQjDmKuzY5QvAcpYjt68 Mk+Y4Cj17gb++T1AUOpy =HpxD -END PGP SIGNATURE- -- Johan
Re: Handling non-reproducible test failures (was Re: 1.7.20 release candidates up for testing/signing)
On Fri, Mar 20, 2015 at 10:30 AM, Johan Corveleyn wrote: > On Fri, Mar 20, 2015 at 9:42 AM, Johan Corveleyn > wrote: > ... > > Unfortunately, I can't verify the rev > > file, since I don't have it anymore, it has been overwritten by trying > > to reproduce it (g, should remember to backup leftover > > repositories and working copies after a failed test run, before trying > > to reproduce it). Whatever I try now, I can't reproduce it anymore > > :-(. > > I'm wondering if something can be improved in our test suite to help > diagnosis of hard-to-reproduce test failures. When this happens, you > typically wish you could analyse as much data as possible (i.e. the > potentially corrupt repository, working copy, dump file, ... that was > used in the test). > > Currently, I can think of three causes for losing this information: > > 1) You run a series of test runs in sequence from a script > (ra_local, ra_svn, ra_serf), all using the same target directory for > running the tests (R:\test in my case, where R: is a ram drive). If > something fails in ra_svn, but succeeds in ra_serf, your broken test > data is overwritten. > > 2) You don't know in advance that the failure will turn out to be > non-reproducible. You can't believe your eyes, try to run it again to > be sure, and lo and behold, the test succeeds (and the broken test > data is overwritten), and succeeds ever since. > > 3) Your test data is on a RAM drive, and you reboot or something. Or > you copy the data to a fixed disk afterwards, but lose a bit of > information because last-modified timestamps of the copied files are > reset by copying them between disks. > > > For 1, maybe the outer script could detect that ra_svn had a failure, > and stop there (does win-tests.py emit an exit code != 0 if there is a > test failure? That would make it easy. Otherwise the outer script > would have to parse the test summary output)? > > Another option is to let every separate test run (ra_local, ra_svn, > ra_serf) use a distinct target test directory. But if you're running > them on a RAM disk, theoretically you might need three times the > storage (hm, maybe not, because --cleanup ensures that successful test > data is cleaned up, so as long as you don't run the three ways in > parallel, it should be fine). I guess I will do that already, and > adjust my script accordingly. > > > Addressing 2 seems harder. Can the second test execution, on > encountering stale test data, put that data aside instead of > overwriting it? Or maybe every test execution can use a unique naming > pattern (with a timestamp or a pid) so it doesn't overwrite previous > data? Both approaches would leak data from failed test runs of course, > but that's more or less the point. OTOH, you don't know that stale > test data is from a previous failed run, or from a successful run that > did not use --cleanup. > > > And 3, well, I already reboot as little as possible, so this is more > just a point of attention. > > > Maybe addressing all three at the same time could also be: after a > failed test run, automatically zip the test data and copy it to a safe > location (e.g. the user's home dir). > > Thoughts? > I haven't thought too deeply about it but I think we should be able to extend the current repo / w/c cleanup infrastructure to copy the data away upon test failure. -- Stefan^2.
Re: 1.7.20 release candidates up for testing/signing
Summary: +1 to release Platform: Linux (Debian/jessie) 64-bit Linux (Centos 6) 64-bit (swig-pl, swig-rb) Tested: (local, svn, svn/sasl, neon, serf) x (fsfs, fsfs/pack/shard, bdb) swig-pl, swig-py, swig-rb, ctypes-python javahl x (fsfs, bdb) swig-pl and swig-rb on Centos 6 as they do not build on Debian/jessie. Results: All tests passed. Local dependencies: apache2-dev : 2.4.10-9 libapr1-dev : 1.5.1-3 libaprutil1-dev : 1.5.4-1 libdb5.3-dev : 5.3.28-9 libsasl2-dev : 2.1.26.dfsg1-13 libsqlite3-dev : 3.8.7.1-1 python2.7-dev : 2.7.9-2 openjdk-7-jdk : 7u75-2.5.4-2 libneon27-dev : 0.30.1-1 serf : 1.3.x@2474 subversion-1.7.20.tar.bz2 -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAABCAAGBQJVDF6LAAoJEHbXiOHtGlmckK0H/1GL928jtLgy3a/Fe224pCdg YJ75Fwqr97Cl0+98R6KbJopRmtdwRyM44e6n8pdjxvt6rQLODMUz9VECToUyqo5E a4LFcDoCfIwzg8ERB+lVjrIFZS7CCtGug+6GyHXVGGZ4wsoCjvqZDNUm+gK5grnK JQXn54BQOFWrLlqVnGZQFyzAVqTJRXbL0HOc+0BimvA2RXQoCnqki0+DIqLwxpAi qf5JWq8wG/8bFMBXU/0U8ziHMQJEBXctuU90ZMk5PJnrl/KUliWNAJx9SHS2FriJ b4jpxOl691tYThDUtzPIROrERteP3MJR66T8djJnCRDIogbKTYH41JKaq6vpWnQ= =x8KV -END PGP SIGNATURE- subversion-1.7.20.tar.gz -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAABCAAGBQJVDF6LAAoJEHbXiOHtGlmcBA8H/0YKWvKlXoejiNxUArakSlp1 NRmpcJMmOAFulJTHLRR4Fu/DBj+mH3+pBpJCPvqWETyflP0gXHIxIWiGe42r+BIR ces7Z5vZp1YayRgwpmiMwg770z03wsj8Rp1YH+g8ZouNWus3mO7+fq187li1ntuf gfPWlpSNzpociUeNK+68IHmUmTtPNsxO/R4KK3lllg5xlYYYMaFKFZU7WMUgD+LL G78/mE1Vj5NM3YPKCUYajK8wuSTm7hjYIYFA7WKYpX4tVbWNChNUVhBIIR7AvZkY EmnlCrMJwP5mlYq3lsGVdr199o6/MdWUv694n4WdPQX9lSXxdh0vZhmlfNn7p+s= =dVEY -END PGP SIGNATURE- -- Philip Martin | Subversion Committer WANdisco // *Non-Stop Data*
Re: 1.7.20 release candidates up for testing/signing
On Wed, Mar 18, 2015 at 3:09 PM, Stefan Sperling wrote: > The 1.7.20 release is now up for testing/signing at > https://dist.apache.org/repos/dist/dev/subversion > Please add your signatures there. > > The anticipated release day is March 31. > > Note that libsvn_subr/mergeinfo-test 6 and 10 may have occasional failures > (segfaults) due to a one-byte read past a string buffer (which cause a > crash > on OpenBSD and maybe on other platforms as well). > This is not a regression from 1.7.19 where the problem already existed. > Summary: +1 to release Platform Ubuntu 14.04.1 x64, Linux 3.16.0-31-generic SMP Standard dependencies: APR 1.5.0 APR-Util 1.5.3 BDB 5.3.28 GCC 4.8.2 httpd 2.4.7, worker MPM JUnit 4.11 libmagic 5.14 libtool 2.4.2 neon 0.30.0 OpenJDK-7 7u51 OpenSSL 1.0.1f Perl 5.18.2 Python 2.7.5 Ruby 1.9.3 SQLite 3.8.2 Swig 2.0.11 zlib 1.2.8 Manually installed and in-tree dependencies: Serf 0.7.2 ctypesgen svn-r151 Verified: Tarball contents and signatures (fsfs, bdb) x (local, svnserve, neon, serf) check-swig-py check-swig-pl check-javahl check-ctypes-python ./get-deps.sh Results: (known issue) Ruby tests failed to build due to unsupported Ruby version. All tests passed. GPG Signatures committed to the dist/dev/subversion repository. -- Stefan^2.
Re: 1.7.20 release candidates up for testing/signing
On 20.03.2015 08:25, Branko Čibej wrote: > On 18.03.2015 15:09, Stefan Sperling wrote: >> The 1.7.20 release is now up for testing/signing at >> https://dist.apache.org/repos/dist/dev/subversion >> Please add your signatures there. >> >> The anticipated release day is March 31. >> >> Note that libsvn_subr/mergeinfo-test 6 and 10 may have occasional failures >> (segfaults) due to a one-byte read past a string buffer (which cause a crash >> on OpenBSD and maybe on other platforms as well). >> This is not a regression from 1.7.19 where the problem already existed. > > I'm changing my vote to > > -1 > > because the copyright year is wrong. Fix (r1667941) nominated for backport. I'm now convinced that we historically don't care enough about the year in NOTICE and 'svn --version' to stop a release. Back to +1. -- Brane, soon to be in a superposition of -1 and +1 states
Re: 1.7.20 release candidates up for testing/signing
Philip Martin writes: > The Perl bindings do not build on my Debian/testing box. Patching the generated code allows the bindings to build and the tests to work. We should consider bumping the swig version used by 1.7, perhaps to 2.0.9 as used by 1.8. I've not explicitly tested 1.7 with 2.0.9 but my dev build uses 1.7 with 2.0.12. --- subversion/bindings/swig/perl/native/core.c 2015-03-18 13:54:08.0 + +++ subversion/bindings/swig/perl/native/core.c 2015-03-20 00:42:48.660845042 + @@ -1448,7 +1448,6 @@ #undef eof #endif #ifdef bool - #undef bool #endif #ifdef close #undef close --- subversion/bindings/swig/perl/native/svn_client.c 2015-03-18 13:54:12.0 + +++ subversion/bindings/swig/perl/native/svn_client.c 2015-03-20 00:43:29.756371112 + @@ -1448,7 +1448,6 @@ #undef eof #endif #ifdef bool - #undef bool #endif #ifdef close #undef close --- subversion/bindings/swig/perl/native/svn_delta.c2015-03-18 13:54:14.0 + +++ subversion/bindings/swig/perl/native/svn_delta.c2015-03-20 00:43:58.020044476 + @@ -1448,7 +1448,6 @@ #undef eof #endif #ifdef bool - #undef bool #endif #ifdef close #undef close --- subversion/bindings/swig/perl/native/svn_diff.c 2015-03-18 13:54:15.0 + +++ subversion/bindings/swig/perl/native/svn_diff.c 2015-03-20 00:44:02.907987866 + @@ -1448,7 +1448,6 @@ #undef eof #endif #ifdef bool - #undef bool #endif #ifdef close #undef close --- subversion/bindings/swig/perl/native/svn_fs.c 2015-03-18 13:54:17.0 + +++ subversion/bindings/swig/perl/native/svn_fs.c 2015-03-20 00:44:08.515922957 + @@ -1448,7 +1448,6 @@ #undef eof #endif #ifdef bool - #undef bool #endif #ifdef close #undef close --- subversion/bindings/swig/perl/native/svn_ra.c 2015-03-18 13:54:20.0 + +++ subversion/bindings/swig/perl/native/svn_ra.c 2015-03-20 00:44:13.027870783 + @@ -1448,7 +1448,6 @@ #undef eof #endif #ifdef bool - #undef bool #endif #ifdef close #undef close --- subversion/bindings/swig/perl/native/svn_repos.c2015-03-18 13:54:22.0 + +++ subversion/bindings/swig/perl/native/svn_repos.c2015-03-20 00:44:17.371820540 + @@ -1448,7 +1448,6 @@ #undef eof #endif #ifdef bool - #undef bool #endif #ifdef close #undef close --- subversion/bindings/swig/perl/native/svn_wc.c 2015-03-18 13:54:28.0 + +++ subversion/bindings/swig/perl/native/svn_wc.c 2015-03-20 00:44:21.907767778 + @@ -1448,7 +1448,6 @@ #undef eof #endif #ifdef bool - #undef bool #endif #ifdef close #undef close -- Philip Martin | Subversion Committer WANdisco // *Non-Stop Data*
Handling non-reproducible test failures (was Re: 1.7.20 release candidates up for testing/signing)
On Fri, Mar 20, 2015 at 9:42 AM, Johan Corveleyn wrote: ... > Unfortunately, I can't verify the rev > file, since I don't have it anymore, it has been overwritten by trying > to reproduce it (g, should remember to backup leftover > repositories and working copies after a failed test run, before trying > to reproduce it). Whatever I try now, I can't reproduce it anymore > :-(. I'm wondering if something can be improved in our test suite to help diagnosis of hard-to-reproduce test failures. When this happens, you typically wish you could analyse as much data as possible (i.e. the potentially corrupt repository, working copy, dump file, ... that was used in the test). Currently, I can think of three causes for losing this information: 1) You run a series of test runs in sequence from a script (ra_local, ra_svn, ra_serf), all using the same target directory for running the tests (R:\test in my case, where R: is a ram drive). If something fails in ra_svn, but succeeds in ra_serf, your broken test data is overwritten. 2) You don't know in advance that the failure will turn out to be non-reproducible. You can't believe your eyes, try to run it again to be sure, and lo and behold, the test succeeds (and the broken test data is overwritten), and succeeds ever since. 3) Your test data is on a RAM drive, and you reboot or something. Or you copy the data to a fixed disk afterwards, but lose a bit of information because last-modified timestamps of the copied files are reset by copying them between disks. For 1, maybe the outer script could detect that ra_svn had a failure, and stop there (does win-tests.py emit an exit code != 0 if there is a test failure? That would make it easy. Otherwise the outer script would have to parse the test summary output)? Another option is to let every separate test run (ra_local, ra_svn, ra_serf) use a distinct target test directory. But if you're running them on a RAM disk, theoretically you might need three times the storage (hm, maybe not, because --cleanup ensures that successful test data is cleaned up, so as long as you don't run the three ways in parallel, it should be fine). I guess I will do that already, and adjust my script accordingly. Addressing 2 seems harder. Can the second test execution, on encountering stale test data, put that data aside instead of overwriting it? Or maybe every test execution can use a unique naming pattern (with a timestamp or a pid) so it doesn't overwrite previous data? Both approaches would leak data from failed test runs of course, but that's more or less the point. OTOH, you don't know that stale test data is from a previous failed run, or from a successful run that did not use --cleanup. And 3, well, I already reboot as little as possible, so this is more just a point of attention. Maybe addressing all three at the same time could also be: after a failed test run, automatically zip the test data and copy it to a safe location (e.g. the user's home dir). Thoughts? -- Johan
Re: 1.7.20 release candidates up for testing/signing
On Thu, Mar 19, 2015 at 7:42 PM, Philip Martin wrote: > Johan Corveleyn writes: > >> >> svn: E160004: Corrupt node-revision '0.0.r9/882' >> svn: E160004: Missing id field in node-rev > > I don't see that on my Linux box. That's a complaint about the root > node of r9, near the end of the file db/revs/0/0. On my Linux box the > offset is 881 not 882, and the file ends: > > id: 0.0.r9/881 > type: dir > pred: 0.0.r8/0 > count: 9 > text: 9 796 72 72 0bbc6c909be39d253813928a4611c161 > cpath: / > copyroot: 0 / > minfo-cnt: 1 > > 0-1.0.t8-8 modify-dir false true /trunk > > 1-2.0.t8-8 modify-file true false /trunk/1 > > 4-2.0.t8-8 modify-file true false /trunk/2 > > > 881 1018 Thanks for looking this up. Unfortunately, I can't verify the rev file, since I don't have it anymore, it has been overwritten by trying to reproduce it (g, should remember to backup leftover repositories and working copies after a failed test run, before trying to reproduce it). Whatever I try now, I can't reproduce it anymore :-(. On Fri, Mar 20, 2015 at 8:03 AM, Stefan Sperling wrote: > On Thu, Mar 19, 2015 at 07:40:41PM +0100, Johan Corveleyn wrote: >> Wait, did I say "reproducible"? Gah, I had it once, then reproduced it >> shortly after (it's still in my scrollback history), then sent this >> mail, and now I can't reproduce it anymore :-(. I've tried at least 20 >> more times ... This it not fun. >> >> What has changed between the fails and now? > >> - Stopped Apache 2.4.12 which was still running (standalone, separate >> console window). > > Hmm... > Perhaps there was a corrupt revision contents cache that got flushed > by restarting Apache? > > Otherwise, no idea. Thanks for the suggestion, maybe something like that could be the cause. Not exactly a corrupt cache in Apache (because the test failure I had was with ra_svn), but perhaps a leftover corrupt repository on disk, still being locked by apache or ... something like that. Otherwise I don't see how an Apache process could interfere with an svnserve process. I do remember that, before I started the ra_svn tests, I did a short attempt with ra_serf against that particular Apache process (which I had just started then). That test run failed somewhere (because of a known issue of AVG Surf Shield interfering with serf (issue #4175 -- fixed in 1.8 but never backported to 1.7)), and I aborted it (Ctrl-C). After that I left Apache running, disabled AVG Surf Shield, and started a batch script that ran ra_local, ra_svn, ra_neon and ra_serf in sequence. So maybe, just maybe, that first aborted ra_serf run left something broken on disk that was later hit by the ra_svn test run (but not by the ra_local test run that ran first, and not by the ra_neon and ra_serf test runs that came later ???). Anyway, I'm going to leave it at that, and conclude this is some weird one-time local issue. I'll retest ra_svn once more tonight, and if successful I'll commit my signature tonight or tomorrow. -- Johan
Re: 1.7.20 release candidates up for testing/signing
On 18.03.2015 15:09, Stefan Sperling wrote: > The 1.7.20 release is now up for testing/signing at > https://dist.apache.org/repos/dist/dev/subversion > Please add your signatures there. > > The anticipated release day is March 31. > > Note that libsvn_subr/mergeinfo-test 6 and 10 may have occasional failures > (segfaults) due to a one-byte read past a string buffer (which cause a crash > on OpenBSD and maybe on other platforms as well). > This is not a regression from 1.7.19 where the problem already existed. I'm changing my vote to -1 because the copyright year is wrong. Fix (r1667941) nominated for backport. -- Brane
Re: 1.7.20 release candidates up for testing/signing
On Thu, Mar 19, 2015 at 07:40:41PM +0100, Johan Corveleyn wrote: > Wait, did I say "reproducible"? Gah, I had it once, then reproduced it > shortly after (it's still in my scrollback history), then sent this > mail, and now I can't reproduce it anymore :-(. I've tried at least 20 > more times ... This it not fun. > > What has changed between the fails and now? > - Stopped Apache 2.4.12 which was still running (standalone, separate > console window). Hmm... Perhaps there was a corrupt revision contents cache that got flushed by restarting Apache? Otherwise, no idea.
RE: 1.7.20 release candidates up for testing/signing
> -Original Message- > From: Stefan Sperling [mailto:s...@elego.de] > Sent: woensdag 18 maart 2015 15:09 > To: dev@subversion.apache.org > Subject: 1.7.20 release candidates up for testing/signing > > The 1.7.20 release is now up for testing/signing at > https://dist.apache.org/repos/dist/dev/subversion > Please add your signatures there. > > The anticipated release day is March 31. > > Note that libsvn_subr/mergeinfo-test 6 and 10 may have occasional failures > (segfaults) due to a one-byte read past a string buffer (which cause a crash > on OpenBSD and maybe on other platforms as well). > This is not a regression from 1.7.19 where the problem already existed. +1 for release Windows 8.1 x64 Visual Studio 2013 (using ^/subversion/branches/v1.7.x-VS2012-15 patch) [fsfs | bdb] x [local | svn | neon] apr 1.5.1 apr-util 1.5.4 db 4.4.20 expat 2.1.0 httpd 2.4.12 java-sdk 1.8.0_40 mod_dav 2.4.12 neon 0.30.1 openssl 1.0.2 sasl 2.1.26 serf 1.3.8 sqlite 3.8.8.3 zlib 1.2.8 These tests take considerable more testspace than 1.8.x and 1.9.x (especially caused by loglevels), which caused a few local problems, delaying the results. Bert
Re: 1.7.20 release candidates up for testing/signing
Stefan Sperling writes: > The 1.7.20 release is now up for testing/signing at > https://dist.apache.org/repos/dist/dev/subversion > Please add your signatures there. > > The anticipated release day is March 31. > > Note that libsvn_subr/mergeinfo-test 6 and 10 may have occasional failures > (segfaults) due to a one-byte read past a string buffer (which cause a crash > on OpenBSD and maybe on other platforms as well). > This is not a regression from 1.7.19 where the problem already existed. The Perl bindings do not build on my Debian/testing box. This is not a regression from 1.7.19 since the problem is also present there. The 1.7.19 Perl bindings did build when I signed the tarball but I was using the older Debian/stable at the time. The problem is: In file included from core.c:731:0: core.c: In function ‘SWIG_AsCharPtrAndSize’: /usr/lib/x86_64-linux-gnu/perl/5.20/CORE/handy.h:124:34: error: ‘bool’ undeclared (first use in this function) The header line in question is: #define cBOOL(cbool) ((cbool) ? (bool)1 : (bool)0) The core.c in the tarball is generated by SWIG 2.0.4 and has: #ifdef bool #undef bool #endif The Perl bindings do build in 1.8.13 where SWIG 2.0.9 is used and core.c has: #ifdef bool /* Leave if macro is from C99 stdbool.h */ #ifndef __bool_true_false_are_defined #undef bool #endif #endif The Perl bindings also build with the system SWIG 2.0.12 as that generates the same code snippet as 2.0.9. -- Philip Martin | Subversion Committer WANdisco // *Non-Stop Data*
Re: 1.7.20 release candidates up for testing/signing
On 18 March 2015 at 17:09, Stefan Sperling wrote: > The 1.7.20 release is now up for testing/signing at > https://dist.apache.org/repos/dist/dev/subversion > Please add your signatures there. > > The anticipated release day is March 31. > > Note that libsvn_subr/mergeinfo-test 6 and 10 may have occasional failures > (segfaults) due to a one-byte read past a string buffer (which cause a crash > on OpenBSD and maybe on other platforms as well). > This is not a regression from 1.7.19 where the problem already existed. Summary: +1 to release. TESTED: --- [ fsfs ] x [ file | svn | http ] RESULTS: All Tests Pass PLATFORM: - MS Windows 7 Ultimate (x64) Microsoft Visual Studio 2008 Version 9.0.30729.1 SP DEPENDENCIES: - APR: 1.5.1 APR-Util: 1.5.3 Apache HTTPD: 2.2.29 zlib: 1.2.8 OpenSSL: 0.9.8zf sqlite: 3.7.6.3 neon: 0.29.6 Python: 2.6.6 serf: 1.1.1 Signatures: --- (See the appropriate distribution files.) -- Ivan Zhakov CTO | VisualSVN | http://www.visualsvn.com
Re: 1.7.20 release candidates up for testing/signing
Philip Martin writes: > node of r9, near the end of the file db/revs/0/0. On my Linux box the db/revs/0/9 ! -- Philip
Re: 1.7.20 release candidates up for testing/signing
Johan Corveleyn writes: > > svn: E160004: Corrupt node-revision '0.0.r9/882' > svn: E160004: Missing id field in node-rev I don't see that on my Linux box. That's a complaint about the root node of r9, near the end of the file db/revs/0/0. On my Linux box the offset is 881 not 882, and the file ends: id: 0.0.r9/881 type: dir pred: 0.0.r8/0 count: 9 text: 9 796 72 72 0bbc6c909be39d253813928a4611c161 cpath: / copyroot: 0 / minfo-cnt: 1 0-1.0.t8-8 modify-dir false true /trunk 1-2.0.t8-8 modify-file true false /trunk/1 4-2.0.t8-8 modify-file true false /trunk/2 881 1018 -- Philip Martin | Subversion Committer WANdisco // *Non-Stop Data*
Re: 1.7.20 release candidates up for testing/signing
On Thu, Mar 19, 2015 at 6:06 PM, Johan Corveleyn wrote: > On Wed, Mar 18, 2015 at 3:09 PM, Stefan Sperling wrote: >> The 1.7.20 release is now up for testing/signing at >> https://dist.apache.org/repos/dist/dev/subversion >> Please add your signatures there. >> >> The anticipated release day is March 31. >> >> Note that libsvn_subr/mergeinfo-test 6 and 10 may have occasional failures >> (segfaults) due to a one-byte read past a string buffer (which cause a crash >> on OpenBSD and maybe on other platforms as well). >> This is not a regression from 1.7.19 where the problem already existed. > > I get one (reproducible) test failure with ra_svn, in > svndumpfilter_tests.py 2 (svndumpfilter loses mergeinfo): Wait, did I say "reproducible"? Gah, I had it once, then reproduced it shortly after (it's still in my scrollback history), then sent this mail, and now I can't reproduce it anymore :-(. I've tried at least 20 more times ... This it not fun. What has changed between the fails and now? - Ran the testsuite for 1.7.20 over ra_serf (all successful). - Finished dinner. - Drove kid to basketball training. - Stopped Apache 2.4.12 which was still running (standalone, separate console window). - Closed another VS2013 Command Prompt (in which I had tested 1.8.20). It didn't respond to "exit", so I closed it. - Then tried to run "python win-tests.py -c release -u svn://localhost -t svndumpfilter#2 R:\test" again, but now it consistently succeeds. Sigh. Nothing relevant I guess ... -- Johan
Re: 1.7.20 release candidates up for testing/signing
On Wed, Mar 18, 2015 at 3:09 PM, Stefan Sperling wrote: > The 1.7.20 release is now up for testing/signing at > https://dist.apache.org/repos/dist/dev/subversion > Please add your signatures there. > > The anticipated release day is March 31. > > Note that libsvn_subr/mergeinfo-test 6 and 10 may have occasional failures > (segfaults) due to a one-byte read past a string buffer (which cause a crash > on OpenBSD and maybe on other platforms as well). > This is not a regression from 1.7.19 where the problem already existed. I get one (reproducible) test failure with ra_svn, in svndumpfilter_tests.py 2 (svndumpfilter loses mergeinfo): [[[ CMD: svnadmin.exe load --quiet svn-test-work\repositories\svndumpfilter_tests-2 CMD: svn.exe propget svn:mergeinfo -R svn://localhost/svn-test-work/repositories/svndumpfilter_tests-2 --config-dir R:\test\subversion\tests\cmdline\svn-test-work\local_tmp\config --password rayjandom --no-auth-cache --username jrandom CMD: R:\test\subversion\svn\svn.exe propget svn:mergeinfo -R svn://localhost/svn-test-work/repositories/svndumpfilter_tests-2 --config-dir R:\test\subversion\tests\cmdline\svn-test-work\local_tmp\config --password rayjandom --no-auth-cache --username jrandom exited with 1 svn: E160004: Corrupt node-revision '0.0.r9/882' svn: E160004: Missing id field in node-rev Traceback (most recent call last): File "C:\research\svn\dev\subversion-1.7.20\subversion\tests\cmdline\svntest\main.py", line 1319, in run rc = self.pred.run(sandbox) File "C:\research\svn\dev\subversion-1.7.20\subversion\tests\cmdline\svntest\testcase.py", line 176, in run return self.func(sandbox) File "C:\research\svn\dev\subversion-1.7.20\subversion\tests\cmdline\svndumpfilter_tests.py", line 163, in svndumpfilter_loses_mergeinfo sbox.repo_url) File "C:\research\svn\dev\subversion-1.7.20\subversion\tests\cmdline\svntest\actions.py", line 268, in run_and_verify_svn expected_exit, *varargs) File "C:\research\svn\dev\subversion-1.7.20\subversion\tests\cmdline\svntest\actions.py", line 306, in run_and_verify_svn2 exit_code, out, err = main.run_svn(want_err, *varargs) File "C:\research\svn\dev\subversion-1.7.20\subversion\tests\cmdline\svntest\main.py", line 601, in run_svn *(_with_auth(_with_config_dir(varargs File "C:\research\svn\dev\subversion-1.7.20\subversion\tests\cmdline\svntest\main.py", line 350, in run_command None, *varargs) File "C:\research\svn\dev\subversion-1.7.20\subversion\tests\cmdline\svntest\main.py", line 526, in run_command_stdin raise Failure Failure FAIL: svndumpfilter_tests.py 2: svndumpfilter loses mergeinfo ]]] Does this ring a bell for anyone? See full log in attachment. With 1.8.13, all tests were successful (fsfs x [ all ra layers ]). With 1.7.20, ra_local and ra_neon went fine (ra_serf still running). Only this one test failure with ra_svn. I'm not sure if this is a regression, since this is a new laptop / new tool chain. Unless anyone can pinpoint this, I'll try a previous 1.7 version to see if it's a regression somewhere. -- Johan svn-fails.log Description: Binary data
Re: 1.7.20 release candidates up for testing/signing
Summary: +1 to release Platform Mac OS X 10.10.2 Yosemite, build 14C109 Standard dependencies: Apple LLVM version 6.0 (clang-600.0.57) (based on LLVM 3.5svn) APR 1.4.8 APR-Util 1.5.2 zlib 1.2.5 httpd 2.4.9 Python 2.7.6 Perl 5.18.2 ruby 2.0.0p481 (2014-05-08 revision 45883) SQLite 3.8.5 Dependencies from homebrew: SQLite 3.8.8.3 Serf 1.3.8 Neon 0.30.0 OpenSSL 1.0.2 BDB 6.1.19 libmagic 5.22 Other dependencies: Swig 2.0.12 Java 1.8.0_25-b17 JUnit 4.11 Verified: Tarball contents and signatures (fsfs, bdb) x (local, svnserve, dav/serf, dav/neon) with SQLite 3.8.8.3 (fsfs) x (local) with SQLite 3.8.5 check-javahl check-swig-py check-swig-pl New issues: None Known issues: - 'make check-javahl' requires 'make install' - 'make check-swig-py' requires 'make install-swig-py' - 'make davautocheck' requires 'make install' Known issues not re-checked: - 'make check-swig-rb' requires 'make install-swig-rb' -- 'make install-swig-rb' tries to install "something" into the Ruby site dir, which requires root privilege. - 'make swig-rb' doesn't work with Ruby 2.0 that's standard on OSX 10.10. GPG signatures committed to the dist/dev/subversion repository.
Re: 1.7.20 release candidates up for testing/signing
Stefan Sperling wrote: > The 1.7.20 release is now up for testing/signing [...] SUMMARY: +1 to release (Unix) VERIFIED: - SHA1 sums: f600c68010d2fd9a23fc8c6b659099aedac12900 subversion-1.7.20.tar.bz2 e861f85e9df1b5aca903aa6eda15919c454cbda5 subversion-1.7.20.tar.gz Comparing the two compressions of each tar package: Files subversion-1.7.20.tar(bz2) and subversion-1.7.20.tar(gz) are identical TESTED: --- [ fsfs | bdb ] x [ file | svn | http (serf; MPM=worker) | http (neon; MPM=worker) ] swig-py swig-pl javahl cytpes-python (swig-rb not tested, as we don't support Ruby 1.9) RESULTS: All tests passed. PLATFORM: - Ubuntu 14.04 (Linux kernel: 3.13.0-46-generic x86_64) DEPENDENCIES: - APR: 1.5.1 APR-UTIL: 1.5.3 zlib: 1.2.8 OpenSSL: 1.0.1 Apache: 2.4.7 BDB: 5.3.21 sqlite: 3.7.13 Python: 2.7.5/2.7.6 Perl: 5.18.2 Ruby: 1.9.3 java: 1.7.0 junit: 4.11 swig: 2.0.11 serf: 1.3.7 - Julian
1.7.20 release candidates up for testing/signing
The 1.7.20 release is now up for testing/signing at https://dist.apache.org/repos/dist/dev/subversion Please add your signatures there. The anticipated release day is March 31. Note that libsvn_subr/mergeinfo-test 6 and 10 may have occasional failures (segfaults) due to a one-byte read past a string buffer (which cause a crash on OpenBSD and maybe on other platforms as well). This is not a regression from 1.7.19 where the problem already existed.
