STINNER Victor added the comment:
ned The changes for this issue appear to have changed the behavior of
test_sqlite.
David Heh, that's the kind of behavior change I was worried about :(
I don't understand why the test is failing, nor why it is only failing on one
specific buildbot. Does it
Roundup Robot added the comment:
New changeset c73f4dced6aa by Victor Stinner in branch 'default':
Issue #18519: Fix test_sqlite on old versions of libsqlite3
http://hg.python.org/cpython/rev/c73f4dced6aa
--
___
Python tracker rep...@bugs.python.org
STINNER Victor added the comment:
I don't understand the relation between my changesets and this failure.
Ok, I found the reason in the definition of the
_sqlite3_result_error() function. This function behave differently on
old sqlite versions: it raises a new exception. The issue should now
Ned Deily added the comment:
c73f4dced6aa appears to fix the problem on 10.4 Tiger. Thanks!
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18519
___
STINNER Victor added the comment:
There is no more known bug, i'm closing this issue.
--
resolution: - fixed
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18519
___
Ned Deily added the comment:
The changes for this issue appear to have changed the behavior of test_sqlite.
Prior to 5643e873f06e on OS X 10.4 Tiger with the system libsqlite (3.1.3), all
test cases of test_sqlite pass. As of current tip on the same platform, there
are now two failures in
R. David Murray added the comment:
Heh, that's the kind of behavior change I was worried about :(.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18519
___
Roundup Robot added the comment:
New changeset f7a0a4e0ada4 by Victor Stinner in branch 'default':
Issue #18519: the Python authorizer callback of sqlite3 must not raise Python
exceptions
http://hg.python.org/cpython/rev/f7a0a4e0ada4
--
___
Python
STINNER Victor added the comment:
I take it the overflow error is the only one the C code
could ever raise? If so, the patch looks good to me.
Yes, _PyLong_AsInt() was the last function raising Python exception (without
clearing it).
Thanks for your help on fixing this function
--
R. David Murray added the comment:
OK, this makes much more sense to me now :)
I take it the overflow error is the only one the C code could ever raise? If
so, the patch looks good to me.
--
___
Python tracker rep...@bugs.python.org
STINNER Victor added the comment:
Raised by what?
The test raising the assertion error is a Python authorizer callback which
returns a Python int (2**32) larger than a C int ( INT_MAX) and so an
OverflowError is raised in the C authorizer callback.
Are you sure you don't just need to clear
New submission from Ned Deily:
See for instance:
http://buildbot.python.org/all/builders/x86%20Tiger%203.x/builds/6626
I was also able to reproduce and bisect on an OS X 10.5 (Leopard) PPC system:
$ hg bisec -b
The first bad revision is:
changeset: 84704:48a869a39e2d
user:Victor
Roundup Robot added the comment:
New changeset 026593cbc006 by Victor Stinner in branch 'default':
Issue #18519, #18408: Fix sqlite authorizer callback
http://hg.python.org/cpython/rev/026593cbc006
--
nosy: +python-dev
___
Python tracker
STINNER Victor added the comment:
It's not a crash, but an assertion that I added recently: it means that a
previous Python exception is not handled correctly.
The problem is that a first call to _authorizer_callback() raised a Python
exception and returned SQLITE_DENY, but sqlite called
Changes by STINNER Victor victor.stin...@gmail.com:
--
resolution: - fixed
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18519
___
R. David Murray added the comment:
Do you understand why it was called again with the exception set? I'm worried
that there might be a change in behavior here that the tests aren't catching.
--
nosy: +r.david.murray
___
Python tracker
STINNER Victor added the comment:
Before my change, the authorizer callback was called even if an exception
was raised. This is wrong, it is not how python works.
You can try with python 3.3 and an authorizer raising an exception and then
increment an attribute. If I understood correctly, the
R. David Murray added the comment:
Raised by what? I thought the callback *was* the thing raising the
exception? Are you sure you don't just need to clear the exception
if the callback function raises one?
--
___
Python tracker
18 matches
Mail list logo
