[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: depth-test.py failing

From: Branko Čibej <brane_at_wandisco.com>
Date: Mon, 28 Oct 2013 10:07:43 +0100

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


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

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

-- Brane

Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. brane_at_wandisco.com
Received on 2013-10-28 10:08:31 CET

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.