[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Failed fs-test 65 (Was: Re: 1.9.5 up for signing/testing)

From: Branko Čibej <brane_at_apache.org>
Date: Wed, 23 Nov 2016 19:08:33 +0100

On 23.11.2016 18:52, Daniel Shahaf wrote:
> Branko Čibej wrote on Wed, Nov 23, 2016 at 18:37:24 +0100:
>> On 23.11.2016 13:31, Evgeny Kotkov wrote:
>>> Branko Čibej <brane_at_apache.org> writes:
>>>
>>>> New issues:
>>>>
>>>> - fs-test 65 fails with SQLite 3.8.10.2:
>>>> [[[
>>>> svn_tests: E200006: Expected error SVN_ERR_SQLITE_BUSY but got
>>>> SVN_ERR_SQLITE_ERROR
>>>> svn_tests: E200030: sqlite[S10]: disk I/O error
>>>> svn_tests: E200042: Additional errors:
>>>> svn_tests: E200030: sqlite[S10]: disk I/O error
>>>> svn_tests: E200044: SQLite transaction rollback failed
>>>> svn_tests: E200030: sqlite[S1]: cannot rollback - no transaction is active
>>>> svn_tests: E200030: sqlite[S1]: cannot rollback - no transaction is active
>>>> FAIL: fs-test 65: test commit with locked rep-cache
>>>> ]]]
>>> Hi Branko,
>>>
>>> Is this failure reproducible? Does it happen if you run just fs-test#65?
>>>
>>> I tried to witness the failure on my Windows and Linux machines with
>>> SQLite 3.8.10.2, but the test passes for me (the relevant sqlite-test#2
>>> also works fine).
>> It is reproducible whether run as a single test, all of fs-test or the
>> whole test suite; but only with SQLite 3.8.10.2. I suspect it is a test
>> bug, but haven't followed up; could be due to a bug in SQLite itself,
>> e.g., that the older version returns the wrong error code.
>>
>> The only potential problem as far as I can see is that 3.8.10.2 is the
>> version of SQLite shipped with OSX — hence, the version that most
>> binaries will be linking with.
> Does the test pass if you patch it to expect SVN_ERR_SQLITE_ERROR? Once
> the shared lock is released, do subsequent commits operate normally
> (finish timely and update rep-cache.db)?
>
> I.e., does this failure mode have any impact beyond the wrong
> apr_status_t value being returned by svn_fs_commit_txn()?

Yes, it passes if I change that one line in the test.

I just double-checked our rep-cache and SQLite wrapper code and I don't
see any way that SQLite could've returned SQLITE_BUSY and we'd return
SVN_ERR_SQLITE_ERROR instead.

-- Brane
Received on 2016-11-23 19:08:38 CET

This is an archived mail posted to the Subversion Dev mailing list.