Branko Čibej <[email protected]> writes: > On 28.10.2013 10:07, Branko Čibej wrote: >> 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
sqlite3_reset is documented to return an error but I don't think that's the same as failing, it's just propagating any sqlite3_step error. I don't see that there is a bug in our code here, the code path in question is exercised by the regression tests, in particular when attempting to add a duplicate to the rep-cache, and apparently works in those cases. >> >> 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. -- Philip Martin | Subversion Committer WANdisco // *Non-Stop Data*
