On Mon, Feb 17, 2014 at 2:47 AM, Johan Corveleyn <[email protected]> wrote: > On Fri, Feb 14, 2014 at 12:44 AM, Ben Reser <[email protected]> wrote: >> The 1.8.8 release artifacts are now available for testing/signing. >> Please get the tarballs from >> https://dist.apache.org/repos/dist/dev/subversion >> and add your signatures there. I plan to try and release on February >> 19th so please try and get your votes/signatures in place by February 17th. >> >> Note that autoprop_tests.py is known to have spurious failures from time to >> time when libmagic support is enabled and tests are run in parallel. > > I ran into a test failure again, while testing ra_local x fsfs: > > [[[ > W: CWD: > R:\test\subversion\tests\cmdline\svn-test-work\working_copies\tree_conflict_tests-10 > W: EXCEPTION: SVNExpectedStdout > Traceback (most recent call last): > File > "C:\research\svn\client_build\subversion-1.8.8\subversion\tests\cmdline\svntest\main.py", > line 1550, in run > rc = self.pred.run(sandbox) > File > "C:\research\svn\client_build\subversion-1.8.8\subversion\tests\cmdline\svntest\testcase.py", > line 176, in run > return self.func(sandbox) > File > "C:\research\svn\client_build\subversion-1.8.8\subversion\tests\cmdline\tree_conflict_tests.py", > line 685, in merge_file_del_onto_not_same > commit_local_mods=True) > File > "C:\research\svn\client_build\subversion-1.8.8\subversion\tests\cmdline\tree_conflict_tests.py", > line 440, in ensure_tree_conflict > '-m', 'Mods in target branch.') > File > "C:\research\svn\client_build\subversion-1.8.8\subversion\tests\cmdline\svntest\actions.py", > line 282, in run_and_verify_svn > expected_exit, *varargs) > File > "C:\research\svn\client_build\subversion-1.8.8\subversion\tests\cmdline\svntest\actions.py", > line 321, in run_and_verify_svn2 > verify.verify_outputs(message, out, err, expected_stdout, expected_stderr) > File > "C:\research\svn\client_build\subversion-1.8.8\subversion\tests\cmdline\svntest\verify.py", > line 445, in verify_outputs > compare_and_display_lines(message, label, expected, actual, raisable) > File > "C:\research\svn\client_build\subversion-1.8.8\subversion\tests\cmdline\svntest\verify.py", > line 418, in compare_and_display_lines > raise raisable > SVNExpectedStdout > FAIL: tree_conflict_tests.py 10: merge file: del/rpl/mv onto not-same > ]]] > > All other ra_local tests succeeded, and all tests over http and svn > succeeded as well. I cannot reproduce this single failure anymore. > > Running on Windows XP (32 bit), a (shared) release build with VS 2010 > SP1. Tests are run non-parallellized, and with cleanup, on a ramdisk > in a subdirectory (R:\test). > > Looking at this test failure, I can't think of a reason why this would > fail (IIUC, a commit succeeded but nothing was written to stdout), > except if there is some kind of flushing issue. Anyone have any idea? > > Now, I have to admit I was running a game of Starcraft with my sons > while the test suite was running on my laptop (it was a tough battle, > the three of us against three computer players ... we won, thanks). > But I doubt my zerg armies could have interfered with the test, or at > least they shouldn't have ;-). > > Since I also had a failure previously while testing 1.8.6 [1] (a > different failure, with externals_tests.py#8, also non reproducible), > I'm currently not comfortable signing this release, until this failure > can be explained. Either there is some local problem with my laptop > (in which case it's no longer fit for testing), or there is a real > issue that needs some more investigation. > > Dependencies: > Httpd 2.4.4 > Apr 1.4.6 > Apr-Util 1.5.2 > Apr-Iconv 1.2.1 > OpenSSL 1.0.1e > Serf 1.3.4 > SQLite 3.7.17 > ZLib 1.2.8 (without assembly optimizations) > > [1] http://svn.haxx.se/dev/archive-2014-02/0084.shtml >
Tried to reproduce it while putting load on my cpu (using [1]), but no success. While cpu was loaded (one of my two cores fully loaded -- like when I was playing starcraft) I ran tree_conflicts_tests.py 10 times. No problem. I'm giving up, I'm not going to sign. I'm not going to veto either ... I just don't know what happened there, and I don't like it. [1] http://www.fossiltoys.com/cpuload.html -- Johan
