Branko Čibej wrote on Wed, Nov 23, 2016 at 18:37:24 +0100: > On 23.11.2016 13:31, Evgeny Kotkov wrote: > > Branko Čibej <[email protected]> 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()? Cheers, Daniel
