You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Blair Zajac <bl...@orcaware.com> on 2012/04/21 01:19:14 UTC
sqlite3 3.7.11 breaks svnversion: E200030: sqlite: callback requested
query abort
I just got this on my MacPorts svn, the revision number output is missing:
$ svnversion
svn: E200030: sqlite: callback requested query abort
svn: E200030: sqlite: callback requested query abort
$ echo $?
1
I've seen a number of other reports of this issue, including freebsd:
https://www.google.com/search?q=svn%3A+E200030%3A+sqlite%3A+callback+requested+query+abort
This error occurs when sqlite is upgraded to 3.7.11, it works fine with
3.7.10.
Personally, I've only seen this in upgraded wc's, fresh checkouts
haven't failed, but I've only tried it in one checkout.
Blair
RE: sqlite3 3.7.11 breaks svnversion: E200030: sqlite: callback requested query abort
Posted by Bert Huijben <be...@qqmail.nl>.
> -----Original Message-----
> From: Blair Zajac [mailto:blair@orcaware.com]
> Sent: zaterdag 21 april 2012 1:19
> To: dev@subversion.apache.org
> Subject: sqlite3 3.7.11 breaks svnversion: E200030: sqlite: callback
requested
> query abort
>
> I just got this on my MacPorts svn, the revision number output is missing:
>
> $ svnversion
> svn: E200030: sqlite: callback requested query abort
> svn: E200030: sqlite: callback requested query abort
> $ echo $?
> 1
>
> I've seen a number of other reports of this issue, including freebsd:
>
> https://www.google.com/search?q=svn%3A+E200030%3A+sqlite%3A+callback+
> requested+query+abort
>
> This error occurs when sqlite is upgraded to 3.7.11, it works fine with
> 3.7.10.
>
> Personally, I've only seen this in upgraded wc's, fresh checkouts
> haven't failed, but I've only tried it in one checkout.
I wouldn't be surprised if the real cause is an sql statement that we don't
properly reset.
Usually we should have reset all statements before releasing and we should
never trigger this problem.
As svnversion just exits after the command we would never notice the bug,
unless you have this sqlite version. But other api users might see the
problem.
Bert
Re: sqlite3 3.7.11 breaks svnversion: E200030: sqlite: callback
requested query abort
Posted by Hyrum K Wright <hy...@wandisco.com>.
On Sat, Apr 21, 2012 at 5:08 PM, Greg Stein <gs...@gmail.com> wrote:
> On Sat, Apr 21, 2012 at 17:59, Daniel Shahaf <da...@elego.de> wrote:
>> Hyrum K Wright wrote on Sat, Apr 21, 2012 at 16:00:02 -0500:
>>> On Sat, Apr 21, 2012 at 11:51 AM, Stefan Sperling <st...@elego.de> wrote:
>>> > On Sat, Apr 21, 2012 at 07:49:37AM -0500, Hyrum K Wright wrote:
>>> >> On Fri, Apr 20, 2012 at 10:15 PM, Greg Stein <gs...@gmail.com> wrote:
>>> >> > Seems we can/should have a runtime version check? Avoid running with 3.7.11?
>>> >>
>>> >> I dunno. Arguably, there are bugs in many versions of our dependency
>>> >> libraries which affect us, yet we don't special case them out. By the
>>> >> time anybody upgrades their Subversion to obtain the version check,
>>> >> they'll probably have upgraded their SQLite as well, so I don't see it
>>> >> as a very big issue.
>
> Yeah, but 3.7.11 is the "current" version, and we don't know when the
> next version will be released. But if we know 1.7.5 is going out
> "now", then we can add a check. And who knows about package skew for
> the next year or so...
http://www.sqlite.org/draft/releaselog/3_7_12.html says May 4, so
roughly two weeks. Though much like our own releases, they are done
when they are done.
> Maybe I don't understand the bug entirely, but it seems "don't use
> this at all" is where we're at. That is very different from some bug
> in apr 1.3.2. If this sqlite issue makes svn a total non-starter, then
> I think we ought to warn about it.
>
> And best way is with a runtime check. We could also have a compile
> time check, which helps packagers.
>
> Blair? How badly did this really impact svn? It sounds like it was
> only for an upgraded working copy? Upgraded from 1.6? I wonder how an
> upgraded wc would differ from a normal checkout... ??
>
>>> > I think we should block or at least warn about dependencies with known
>>> > bugs. There should be a way to force use of the dependency if necessary
>>> > (like the --disable-neon-version-check option).
>
> Maybe. I think it really depends upon the problem. For example, we
> couldn't even *start* svn with 3.7.7. We had to wait for 3.7.7.1 to be
> released. No about of "check disable" would allow us to run against
> 3.7.7.
>
>>> It's a slippery slope. We've got a number of dependencies, and there
>>> is no possible way to test or even keep up with the various
>>> permutations of them that may be installed. We do our best, but I
>>
>> What permutations? We don't care what the bdb or neon version is when
>
> Right.
>
>> checking the sqlite version, and we don't care if there is more than one
>> sqlite on the system either.
>>
>>> just don't think we ought to litter our code with version checks and
>>> warnings when we get user-reported issues like this. It's a
>>> maintenance nightmare.
>>
>> How so? Did we have more than one or two of those bugs per year?
>
> Furthermore, these checks slowly disappear over time. We used to have
> a lot of version-dependent code in sqlite.c. But then we said "minimum
> version is $whatever" and deleted a bunch of those checks.
>
> If we put in a check to avoid 3.7.11, then it will get deleted once we
> set a 3.8 minimum (for example).
>
> These checks are also pretty darned isolated. They aren't really
> "littered" around the codebase.
>
>>...
>> If we could have the same check either in code or in a documentation
>> somewhere, I'd vote for the former.
>
> I strongly concur.
>
> Cheers,
> -g
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com/
Re: sqlite3 3.7.11 breaks svnversion: E200030: sqlite: callback
requested query abort
Posted by Greg Stein <gs...@gmail.com>.
On Sat, Apr 21, 2012 at 17:59, Daniel Shahaf <da...@elego.de> wrote:
> Hyrum K Wright wrote on Sat, Apr 21, 2012 at 16:00:02 -0500:
>> On Sat, Apr 21, 2012 at 11:51 AM, Stefan Sperling <st...@elego.de> wrote:
>> > On Sat, Apr 21, 2012 at 07:49:37AM -0500, Hyrum K Wright wrote:
>> >> On Fri, Apr 20, 2012 at 10:15 PM, Greg Stein <gs...@gmail.com> wrote:
>> >> > Seems we can/should have a runtime version check? Avoid running with 3.7.11?
>> >>
>> >> I dunno. Arguably, there are bugs in many versions of our dependency
>> >> libraries which affect us, yet we don't special case them out. By the
>> >> time anybody upgrades their Subversion to obtain the version check,
>> >> they'll probably have upgraded their SQLite as well, so I don't see it
>> >> as a very big issue.
Yeah, but 3.7.11 is the "current" version, and we don't know when the
next version will be released. But if we know 1.7.5 is going out
"now", then we can add a check. And who knows about package skew for
the next year or so...
Maybe I don't understand the bug entirely, but it seems "don't use
this at all" is where we're at. That is very different from some bug
in apr 1.3.2. If this sqlite issue makes svn a total non-starter, then
I think we ought to warn about it.
And best way is with a runtime check. We could also have a compile
time check, which helps packagers.
Blair? How badly did this really impact svn? It sounds like it was
only for an upgraded working copy? Upgraded from 1.6? I wonder how an
upgraded wc would differ from a normal checkout... ??
>> > I think we should block or at least warn about dependencies with known
>> > bugs. There should be a way to force use of the dependency if necessary
>> > (like the --disable-neon-version-check option).
Maybe. I think it really depends upon the problem. For example, we
couldn't even *start* svn with 3.7.7. We had to wait for 3.7.7.1 to be
released. No about of "check disable" would allow us to run against
3.7.7.
>> It's a slippery slope. We've got a number of dependencies, and there
>> is no possible way to test or even keep up with the various
>> permutations of them that may be installed. We do our best, but I
>
> What permutations? We don't care what the bdb or neon version is when
Right.
> checking the sqlite version, and we don't care if there is more than one
> sqlite on the system either.
>
>> just don't think we ought to litter our code with version checks and
>> warnings when we get user-reported issues like this. It's a
>> maintenance nightmare.
>
> How so? Did we have more than one or two of those bugs per year?
Furthermore, these checks slowly disappear over time. We used to have
a lot of version-dependent code in sqlite.c. But then we said "minimum
version is $whatever" and deleted a bunch of those checks.
If we put in a check to avoid 3.7.11, then it will get deleted once we
set a 3.8 minimum (for example).
These checks are also pretty darned isolated. They aren't really
"littered" around the codebase.
>...
> If we could have the same check either in code or in a documentation
> somewhere, I'd vote for the former.
I strongly concur.
Cheers,
-g
Re: sqlite3 3.7.11 breaks svnversion: E200030: sqlite: callback
requested query abort
Posted by Daniel Shahaf <da...@elego.de>.
Hyrum K Wright wrote on Sat, Apr 21, 2012 at 16:00:02 -0500:
> On Sat, Apr 21, 2012 at 11:51 AM, Stefan Sperling <st...@elego.de> wrote:
> > On Sat, Apr 21, 2012 at 07:49:37AM -0500, Hyrum K Wright wrote:
> >> On Fri, Apr 20, 2012 at 10:15 PM, Greg Stein <gs...@gmail.com> wrote:
> >> > Seems we can/should have a runtime version check? Avoid running with 3.7.11?
> >>
> >> I dunno. Arguably, there are bugs in many versions of our dependency
> >> libraries which affect us, yet we don't special case them out. By the
> >> time anybody upgrades their Subversion to obtain the version check,
> >> they'll probably have upgraded their SQLite as well, so I don't see it
> >> as a very big issue.
> >
> > I think we should block or at least warn about dependencies with known
> > bugs. There should be a way to force use of the dependency if necessary
> > (like the --disable-neon-version-check option).
>
> It's a slippery slope. We've got a number of dependencies, and there
> is no possible way to test or even keep up with the various
> permutations of them that may be installed. We do our best, but I
What permutations? We don't care what the bdb or neon version is when
checking the sqlite version, and we don't care if there is more than one
sqlite on the system either.
> just don't think we ought to litter our code with version checks and
> warnings when we get user-reported issues like this. It's a
> maintenance nightmare.
How so? Did we have more than one or two of those bugs per year?
>
> > Whether or not a given system has version A of dependency X is often
> > not a direct decision made by the system's users. For example, a buggy
> > dependency might slip into a long-term supported release of systems
> > people use (Debian stale, Redhat, and the like). It's better to make
> > packagers aware of known problems at build time, rather than waiting
> > for users of the packages to find problems and file duplicate reports.
>
> I would go a step further and say it's better to let packagers know
> though the documentation, rather than via technical means. Put
> somewhere on the website the list of deps versions which break
> Subversion. We may not expect typical users to refer to this, but I
> think we can hold packagers to the higher standard.
>
If we could have the same check either in code or in a documentation
somewhere, I'd vote for the former.
> -Hyrum
>
>
>
> --
>
> uberSVN: Apache Subversion Made Easy
> http://www.uberSVN.com/
Re: sqlite3 3.7.11 breaks svnversion: E200030: sqlite: callback
requested query abort
Posted by Hyrum K Wright <hy...@wandisco.com>.
On Sat, Apr 21, 2012 at 11:51 AM, Stefan Sperling <st...@elego.de> wrote:
> On Sat, Apr 21, 2012 at 07:49:37AM -0500, Hyrum K Wright wrote:
>> On Fri, Apr 20, 2012 at 10:15 PM, Greg Stein <gs...@gmail.com> wrote:
>> > Seems we can/should have a runtime version check? Avoid running with 3.7.11?
>>
>> I dunno. Arguably, there are bugs in many versions of our dependency
>> libraries which affect us, yet we don't special case them out. By the
>> time anybody upgrades their Subversion to obtain the version check,
>> they'll probably have upgraded their SQLite as well, so I don't see it
>> as a very big issue.
>
> I think we should block or at least warn about dependencies with known
> bugs. There should be a way to force use of the dependency if necessary
> (like the --disable-neon-version-check option).
It's a slippery slope. We've got a number of dependencies, and there
is no possible way to test or even keep up with the various
permutations of them that may be installed. We do our best, but I
just don't think we ought to litter our code with version checks and
warnings when we get user-reported issues like this. It's a
maintenance nightmare.
> Whether or not a given system has version A of dependency X is often
> not a direct decision made by the system's users. For example, a buggy
> dependency might slip into a long-term supported release of systems
> people use (Debian stale, Redhat, and the like). It's better to make
> packagers aware of known problems at build time, rather than waiting
> for users of the packages to find problems and file duplicate reports.
I would go a step further and say it's better to let packagers know
though the documentation, rather than via technical means. Put
somewhere on the website the list of deps versions which break
Subversion. We may not expect typical users to refer to this, but I
think we can hold packagers to the higher standard.
-Hyrum
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com/
Re: sqlite3 3.7.11 breaks svnversion: E200030: sqlite: callback
requested query abort
Posted by Stefan Sperling <st...@elego.de>.
On Sat, Apr 21, 2012 at 07:49:37AM -0500, Hyrum K Wright wrote:
> On Fri, Apr 20, 2012 at 10:15 PM, Greg Stein <gs...@gmail.com> wrote:
> > Seems we can/should have a runtime version check? Avoid running with 3.7.11?
>
> I dunno. Arguably, there are bugs in many versions of our dependency
> libraries which affect us, yet we don't special case them out. By the
> time anybody upgrades their Subversion to obtain the version check,
> they'll probably have upgraded their SQLite as well, so I don't see it
> as a very big issue.
I think we should block or at least warn about dependencies with known
bugs. There should be a way to force use of the dependency if necessary
(like the --disable-neon-version-check option).
Whether or not a given system has version A of dependency X is often
not a direct decision made by the system's users. For example, a buggy
dependency might slip into a long-term supported release of systems
people use (Debian stale, Redhat, and the like). It's better to make
packagers aware of known problems at build time, rather than waiting
for users of the packages to find problems and file duplicate reports.
Re: sqlite3 3.7.11 breaks svnversion: E200030: sqlite: callback
requested query abort
Posted by Hyrum K Wright <hy...@wandisco.com>.
On Fri, Apr 20, 2012 at 10:15 PM, Greg Stein <gs...@gmail.com> wrote:
>
> On Apr 20, 2012 9:41 PM, "Blair Zajac" <bl...@orcaware.com> wrote:
>>
>>
>> On Apr 20, 2012, at 5:22 PM, Hyrum K Wright wrote:
>>
>>> On Fri, Apr 20, 2012 at 6:19 PM, Blair Zajac <bl...@orcaware.com> wrote:
>>>>
>>>> I just got this on my MacPorts svn, the revision number output is
>>>> missing:
>>>>
>>>> $ svnversion
>>>> svn: E200030: sqlite: callback requested query abort
>>>> svn: E200030: sqlite: callback requested query abort
>>>> $ echo $?
>>>> 1
>>>>
>>>> I've seen a number of other reports of this issue, including freebsd:
>>>>
>>>>
>>>> https://www.google.com/search?q=svn%3A+E200030%3A+sqlite%3A+callback+requested+query+abort
>>>>
>>>> This error occurs when sqlite is upgraded to 3.7.11, it works fine with
>>>> 3.7.10.
>>>>
>>>> Personally, I've only seen this in upgraded wc's, fresh checkouts
>>>> haven't
>>>> failed, but I've only tried it in one checkout.
>>>
>>>
>>> We use the RELEASE statement, which has a bug in 3.7.11, scheduled to
>>> be fixed in 3.7.12. From
>>> http://www.sqlite.org/draft/releaselog/3_7_12.html: "Bug fix: Fix the
>>> RELEASE command so that it does not cancel pending queries. This
>>> repairs a problem introduced in 3.7.11"
>>>
>>> On the surface, this sounds like what your problem is.
>>
>>
>> Hi Hyrum,
>>
>> Thanks for the info. We'll wait for 3.7.12.
>
> Seems we can/should have a runtime version check? Avoid running with 3.7.11?
I dunno. Arguably, there are bugs in many versions of our dependency
libraries which affect us, yet we don't special case them out. By the
time anybody upgrades their Subversion to obtain the version check,
they'll probably have upgraded their SQLite as well, so I don't see it
as a very big issue.
-Hyrum
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com/
Re: sqlite3 3.7.11 breaks svnversion: E200030: sqlite: callback
requested query abort
Posted by Daniel Shahaf <da...@elego.de>.
Greg Stein wrote on Fri, Apr 20, 2012 at 23:15:05 -0400:
> Seems we can/should have a runtime version check? Avoid running with 3.7.11?
+1
Index: subversion/libsvn_subr/sqlite.c
===================================================================
--- subversion/libsvn_subr/sqlite.c (revision 1327986)
+++ subversion/libsvn_subr/sqlite.c (working copy)
@@ -747,6 +747,16 @@ svn_sqlite__open(svn_sqlite__db_t **db, const char
int unused1, const char * const *unused2,
apr_pool_t *result_pool, apr_pool_t *scratch_pool)
{
+#if !SQLITE_VERSION_AT_LEAST(3,7,12)
+ const char *runtime_version = sqlite3_libversion();
+
+ /* Bug in the RELEASE statement, schedule to be fixed in 3.7.12. */
+ if (!strcmp(runtime_version, "3.7.11"))
+ return svn_error_createf(SVN_ERR_UNSUPPORTED_FEATURE, NULL,
+ _("Cannot use SQLite 3.7.11; upgrade to 3.7.12 "
+ "or downgrade to 3.7.10"));
+#endif /* lt 3.7.12 */
+
SVN_ERR(svn_atomic__init_once(&sqlite_init_state,
init_sqlite, NULL, scratch_pool));
@@ -774,10 +784,11 @@ svn_sqlite__open(svn_sqlite__db_t **db, const char
*/
{
int ignored_err = SQLITE_OK;
+
#if !SQLITE_VERSION_AT_LEAST(3,7,8) && defined(SQLITE_SCHEMA)
- if (!strcmp(sqlite3_libversion(), "3.7.7"))
+ if (!strcmp(runtime_version, "3.7.7"))
ignored_err = SQLITE_SCHEMA;
-#endif
+#endif /* lt 3.7.8 && defined(SQLITE_SCHEMA) */
SVN_ERR(exec_sql2(*db, "PRAGMA case_sensitive_like=1;", ignored_err));
}
Re: sqlite3 3.7.11 breaks svnversion: E200030: sqlite: callback
requested query abort
Posted by Greg Stein <gs...@gmail.com>.
On Apr 20, 2012 9:41 PM, "Blair Zajac" <bl...@orcaware.com> wrote:
>
>
> On Apr 20, 2012, at 5:22 PM, Hyrum K Wright wrote:
>
>> On Fri, Apr 20, 2012 at 6:19 PM, Blair Zajac <bl...@orcaware.com> wrote:
>>>
>>> I just got this on my MacPorts svn, the revision number output is
missing:
>>>
>>> $ svnversion
>>> svn: E200030: sqlite: callback requested query abort
>>> svn: E200030: sqlite: callback requested query abort
>>> $ echo $?
>>> 1
>>>
>>> I've seen a number of other reports of this issue, including freebsd:
>>>
>>>
https://www.google.com/search?q=svn%3A+E200030%3A+sqlite%3A+callback+requested+query+abort
>>>
>>> This error occurs when sqlite is upgraded to 3.7.11, it works fine with
>>> 3.7.10.
>>>
>>> Personally, I've only seen this in upgraded wc's, fresh checkouts
haven't
>>> failed, but I've only tried it in one checkout.
>>
>>
>> We use the RELEASE statement, which has a bug in 3.7.11, scheduled to
>> be fixed in 3.7.12. From
>> http://www.sqlite.org/draft/releaselog/3_7_12.html: "Bug fix: Fix the
>> RELEASE command so that it does not cancel pending queries. This
>> repairs a problem introduced in 3.7.11"
>>
>> On the surface, this sounds like what your problem is.
>
>
> Hi Hyrum,
>
> Thanks for the info. We'll wait for 3.7.12.
Seems we can/should have a runtime version check? Avoid running with 3.7.11?
Cheers,
-g
Re: sqlite3 3.7.11 breaks svnversion: E200030: sqlite: callback requested query abort
Posted by Blair Zajac <bl...@orcaware.com>.
On Apr 20, 2012, at 5:22 PM, Hyrum K Wright wrote:
> On Fri, Apr 20, 2012 at 6:19 PM, Blair Zajac <bl...@orcaware.com>
> wrote:
>> I just got this on my MacPorts svn, the revision number output is
>> missing:
>>
>> $ svnversion
>> svn: E200030: sqlite: callback requested query abort
>> svn: E200030: sqlite: callback requested query abort
>> $ echo $?
>> 1
>>
>> I've seen a number of other reports of this issue, including freebsd:
>>
>> https://www.google.com/search?q=svn%3A+E200030%3A+sqlite%3A+callback+requested+query+abort
>>
>> This error occurs when sqlite is upgraded to 3.7.11, it works fine
>> with
>> 3.7.10.
>>
>> Personally, I've only seen this in upgraded wc's, fresh checkouts
>> haven't
>> failed, but I've only tried it in one checkout.
>
> We use the RELEASE statement, which has a bug in 3.7.11, scheduled to
> be fixed in 3.7.12. From
> http://www.sqlite.org/draft/releaselog/3_7_12.html: "Bug fix: Fix the
> RELEASE command so that it does not cancel pending queries. This
> repairs a problem introduced in 3.7.11"
>
> On the surface, this sounds like what your problem is.
Hi Hyrum,
Thanks for the info. We'll wait for 3.7.12.
Blair
Re: sqlite3 3.7.11 breaks svnversion: E200030: sqlite: callback
requested query abort
Posted by Hyrum K Wright <hy...@wandisco.com>.
On Fri, Apr 20, 2012 at 6:19 PM, Blair Zajac <bl...@orcaware.com> wrote:
> I just got this on my MacPorts svn, the revision number output is missing:
>
> $ svnversion
> svn: E200030: sqlite: callback requested query abort
> svn: E200030: sqlite: callback requested query abort
> $ echo $?
> 1
>
> I've seen a number of other reports of this issue, including freebsd:
>
> https://www.google.com/search?q=svn%3A+E200030%3A+sqlite%3A+callback+requested+query+abort
>
> This error occurs when sqlite is upgraded to 3.7.11, it works fine with
> 3.7.10.
>
> Personally, I've only seen this in upgraded wc's, fresh checkouts haven't
> failed, but I've only tried it in one checkout.
We use the RELEASE statement, which has a bug in 3.7.11, scheduled to
be fixed in 3.7.12. From
http://www.sqlite.org/draft/releaselog/3_7_12.html: "Bug fix: Fix the
RELEASE command so that it does not cancel pending queries. This
repairs a problem introduced in 3.7.11"
On the surface, this sounds like what your problem is.
-Hyrum
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com/