Re: 1.8.8 up for testing/signing

On Tue, Feb 18, 2014 at 5:22 PM, Ben Reser <ben_at_reser.org> wrote:
> On 2/17/14, 3:27 PM, Johan Corveleyn wrote:
>> On Mon, Feb 17, 2014 at 2:47 AM, Johan Corveleyn <jcorvel_at_gmail.com> wrote:
>>> On Fri, Feb 14, 2014 at 12:44 AM, Ben Reser <ben_at_reser.org> 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
>
> Possibly related to:
> [[[
> r1544028 | svn-role | 2013-11-20 20:02:55 -0800 (Wed, 20 Nov 2013) | 11 lines
>
> Merge the r1499470 group from trunk:
>
> * r1499470, r1543413
> Flush stdout before exiting svn with an error.
> Justification:
> Without this patch merge_tests.py 135 may fail to output its required
> output.
> Votes:
> +1: ivan (without r1543413)
> +1: rhuijben, stsp, pburba
> ]]]
>
> There is a related change on trunk that has not been backported to my knowledge:
> https://svn.apache.org/r1543868
>
> The backported revisions only resolve the error cases the above revision
> resolves also the successful cases. Maybe you're running into a random failure
> due to this?

Thanks for the hint. Now, this wasn't an error path (just a commit
that should have succeeded and should've written something to stdout).
I'm not sure how I can determine that this is the likely cause ... I
can't seem to reproduce it, no matter how hard I try :-(.

Bert also suggested another possible reason: perhaps it was no
flushing problem, but rather that the commit didn't do anything
because the commit crawler didn't find any mods (perhaps because of
timestamp granularity stuff). If my ramdisk would have been a FAT32
partition, that might be a possible explanation, but "unfortunately"
it's an NTFS ramdisk ... I don't see how this could have happened.
Perhaps someone can hypothesize something, and talk me through a
possible scenario?

-- 
Johan