Branko Čibej <brane_at_wandisco.com> 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*
Received on 2013-10-28 12:25:22 CET