On 28.10.2013 10:07, Branko Čibej wrote: > On 28.10.2013 07:03, Branko Čibej wrote: >> On 27.10.2013 03:36, Branko Čibej wrote: >>> I'm getting really weird failures in depth-test.py on Mac OS. I noticed >>> it first in my trunk working copy (out-of-source build); a test was >>> asserting in libsvn_subr/sqlite.c:856 (i.e., a statement was not >>> properly reset). I couldn't find the reason, but since I had local >>> modifications that shouldn't have affected that part of the code, I was >>> worried. >>> >>> I checked out another copy of trunk and transferred the local mods over, >>> one file at a time, recompiling and re-running the test each time ... >>> the test passed. Re-ran whole tests, all tests passed again. Tried the >>> same with an out-of-trree build with the same configuration as the >>> original build ... the test still passed. >>> >>> Then I ran /all/ the tests -- and depth-test.py failed, but a >>> /different/ test this time. I thought, well, that's weird; so I cleaned >>> out svn-test-work and ran just depth-test.py ... and it failed again and >>> keeps failing. >>> >>> I'm a bit at a loss now. Any ideas? Before you ask: valgrind is not >>> reliable on the Mac. >> Well, the failure is definitely real. I just Built Subversion on a >> completely fresh Mac Mini, without homebrew etc. -- just the latest >> autoconf and libtool. The same test fails as before. I'm going to do >> some bisecting to try to find the commit that caused this. > Here's the error in fails.log: > > W: subversion/svn/update-cmd.c:172, > W: subversion/libsvn_client/update.c:722, > W: subversion/libsvn_client/update.c:614, > W: subversion/libsvn_client/update.c:328, > W: subversion/libsvn_wc/crop.c:357, > W: subversion/libsvn_wc/crop.c:149, > W: subversion/libsvn_wc/wc_db.c:7223, > W: subversion/libsvn_subr/sqlite.c:1251, > W: subversion/libsvn_wc/wc_db.c:7077, > W: subversion/libsvn_subr/sqlite.c:313: (apr_err=SVN_ERR_SQLITE_ERROR) > W: svn: E200030: sqlite[S4]: callback requested query abort > W: subversion/libsvn_subr/sqlite.c:710: (apr_err=SVN_ERR_SQLITE_ERROR) > W: svn: E200030: Additional errors: > W: subversion/libsvn_subr/sqlite.c:710: (apr_err=SVN_ERR_SQLITE_ERROR) > W: svn: E200030: sqlite[S4]: callback requested query abort > W: CWD: > /Users/brane/src/svn/repos/tunk-checksomething/subversion/tests/cmdline > W: EXCEPTION: Failure: Command failed: > "/Users/brane/src/svn/repos/tunk-checksomething/subversion/svn/svn up > --set-depth empty ..."; exit code 1 > > > It turns out that sqlite3_reset fails, which is why we ultimately get > the assertion during pool cleanup. This appears to be due to a bug in > our code; we call svn_sqlite__reset (and thus sqlite3_reset) if > sqlite3_step fails (this is line 316 in sqlite.c), and that is > documented to fail as per > > http://www.sqlite.org/c3ref/reset.html > > The original failure of sqlit3_step is: > > svn: E200030: sqlite[S4]: callback requested query abort > > and this happens within svn_wc__db_op_remove_node. I don't understand > which "callback" is supposed to have "requested query abort" since we > don't use any callbacks (the debug and performance callbacks were not > enabled). > > Both of the machines this fails on are OSX 10.8.5; Both have Xcode 5 > (5.0.0 in one case, 5.0.1 in the other); both use the stock OSX SQLite > 3.7.12.
Upgrading to amalgamated SQLite 3.7.15.1 causes the failure to go away. I propose we make this the minimal supported version, since at least on Mac OS, 3.7.12 doesn't cut it. -- Brane -- Branko Čibej | Director of Subversion WANdisco // Non-Stop Data e. [email protected]
