You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Branko Čibej <br...@wandisco.com> on 2013/10/27 03:36:55 UTC
depth-test.py failing
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.
-- Brane
--
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. brane@wandisco.com
Re: depth-test.py failing
Posted by Philip Martin <ph...@wandisco.com>.
Branko Čibej <br...@wandisco.com> writes:
>> We should write a regression test for out SQLite wrapper code with a
>> statement that has a successful step before a failed step. Does that
>> mean it has to be a SELECT? If so, how do we get it to fail after a
>> successful step? Could we use a scalar function to do that sort of
>> thing?
>
> Maybe just try to run the tests with SQLite 3.7.12 ... worked like a
> charm for me to reproduce this error. Of course, I still have no idea
> whatsoever why the step failed, the error message isn't very informative.
3.7.12 doesn't fail in my Linux box. I added a regression test for
svn_sqlite__reset using a scalar function but I'm not sure how much it
really tests as I could not get it to fail. By experiment I see that
the sqlite3_reset call after a failed sqlite3_step call returns the same
error as the the failed sqlite3_step, but it also does the reset so a
second sqlite3_reset call doesn't return the error.
--
Philip Martin | Subversion Committer
WANdisco // *Non-Stop Data*
Re: depth-test.py failing
Posted by Branko Čibej <br...@wandisco.com>.
On 28.10.2013 13:48, Philip Martin wrote:
> Branko Čibej <br...@wandisco.com> writes:
>
>> On 28.10.2013 12:24, Philip Martin wrote:
>>> Branko Čibej <br...@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).
> So we rely on this code in svn_fs_fs__set_rep_reference, perhaps other
> places as well, but it works ther because the statement is an INSERT and
> there is only ever one step, so needs_reset is never set.
Bert just changed svn_sqlite__reset to do something slightly better in
that the result is more predictable, regardless of previous errors.
> We should write a regression test for out SQLite wrapper code with a
> statement that has a successful step before a failed step. Does that
> mean it has to be a SELECT? If so, how do we get it to fail after a
> successful step? Could we use a scalar function to do that sort of
> thing?
Maybe just try to run the tests with SQLite 3.7.12 ... worked like a
charm for me to reproduce this error. Of course, I still have no idea
whatsoever why the step failed, the error message isn't very informative.
-- Brane
--
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. brane@wandisco.com
Re: depth-test.py failing
Posted by Philip Martin <ph...@wandisco.com>.
Branko Čibej <br...@wandisco.com> writes:
> On 28.10.2013 12:24, Philip Martin wrote:
>> Branko Čibej <br...@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).
So we rely on this code in svn_fs_fs__set_rep_reference, perhaps other
places as well, but it works ther because the statement is an INSERT and
there is only ever one step, so needs_reset is never set.
We should write a regression test for out SQLite wrapper code with a
statement that has a successful step before a failed step. Does that
mean it has to be a SELECT? If so, how do we get it to fail after a
successful step? Could we use a scalar function to do that sort of
thing?
--
Philip Martin | Subversion Committer
WANdisco // *Non-Stop Data*
Re: depth-test.py failing
Posted by Branko Čibej <br...@wandisco.com>.
On 28.10.2013 12:24, Philip Martin wrote:
> Branko Čibej <br...@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@wandisco.com
Re: depth-test.py failing
Posted by Philip Martin <ph...@wandisco.com>.
Branko Čibej <br...@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*
Re: depth-test.py failing
Posted by Branko Čibej <br...@wandisco.com>.
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@wandisco.com
Re: depth-test.py failing
Posted by Branko Čibej <br...@wandisco.com>.
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.
-- Brane
--
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. brane@wandisco.com
Re: depth-test.py failing
Posted by Branko Čibej <br...@wandisco.com>.
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.
-- Brane
--
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. brane@wandisco.com