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