On 28.10.2013 12:24, Philip Martin wrote:
> 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.
The result is that we get the same error in the chain twice; we don't
actually know that the statement is reset; and on top of everything
else, in such cases we do not clear the svn_sqlite__stmt_t::needs_reset
flag, which leads to another error during pool cleanup (or an abort in
maintainer mode).
Doesn't seem right to me to abort in that case. If we can be 100% sure
that sqlite3_reset just propagates the error but does in fact reset the
statement, then we should clear the needs_reset flag before erroring out
in svn_sqlite__reset.
-- Brane
--
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. brane_at_wandisco.com
Received on 2013-10-28 13:06:57 CET