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. brane_at_wandisco.com
Received on 2013-10-28 10:19:59 CET