test_sqlite crashes on OS X tiger 3.x buildbot #62719
Comments
|
See for instance: 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 Stinner <victor.stinner@gmail.com>
date: Thu Jul 18 01:41:08 2013 +0200
summary: Issue python/cpython#62608: PyEval_EvalFrameEx() and PyEval_CallObjectWithKeywords() now failCrash and gdb "where" with current tip: $ hg log -r tip
changeset: 84749:5643e873f06e
tag: tip
parent: 84746:c5d128b201af
parent: 84748:db6a22943a3f
user: Ned Deily <nad@acm.org>
date: Sat Jul 20 15:08:22 2013 -0700
summary: Issue python/cpython#61734: merge from 3.3
$ ./python -m test test_sqlite
[1/1] test_sqlite
Assertion failed: (!PyErr_Occurred()), function PyEval_EvalFrameEx, file Python/ceval.c, line 1210.
Fatal Python error: AbortedCurrent thread 0xa0343820: (gdb) -m test -w -uall,-largefile test_sqlite Program received signal SIGABRT, Aborted. |
ned-deily
added
the
type-crash
|
New changeset 026593cbc006 by Victor Stinner in branch 'default': |
|
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 _authorizer_callback() again (with the Python exception set). According to the doc: "SQLITE_DENY to cause the entire SQL statement to be rejected with an error": So I don't expect _authorizer_callback() to be called again if the previous call returned SQLITE_DENY. Whatever, this issue should be fixed by the changeset 026593cbc006. |
|
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. |
|
Before my change, the authorizer callback was called even if an exception You can try with python 3.3 and an authorizer raising an exception and then |
|
Raised by what? I thought the callback *was* the thing raising the |
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.
I read the code one more time, and I saw this: if (_enable_callback_tracebacks) {
PyErr_Print();
} else {
PyErr_Clear();
}So it is expected that the C authorizer callback clears the error. Here is a new patch which implement the same behaviour on _PyLong_AsInt() failure. |
|
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. |
|
New changeset f7a0a4e0ada4 by Victor Stinner in branch 'default': |
Yes, _PyLong_AsInt() was the last function raising Python exception (without clearing it). Thanks for your help on fixing this function |
|
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 test_sqlite: $ ./python -m test -v test_sqlite
== CPython 3.4.0a0 (default:c7d9a2159c6c, Jul 30 2013, 14:20:52) [GCC 4.0.1 (Apple Computer, Inc. build 5370)]
== Darwin-8.11.0-Power_Macintosh-powerpc-32bit big-endian
== /Volumes/cache/py/main4/3x/unix/source/build/test_python_4328
Testing with flags: sys.flags(debug=0, inspect=0, interactive=0, optimize=0, dont_write_bytecode=0, no_user_site=0, no_site=0, ignore_environment=0, verbose=0, bytes_warning=0, quiet=0, hash_randomization=1)
[1/1] test_sqlite
test_sqlite: testing with version '2.6.0', sqlite_version '3.1.3'
[...]====================================================================== Traceback (most recent call last):
File "/Volumes/cache/py/main4/3x/unix/source/Lib/sqlite3/test/userfunctions.py", line 336, in CheckAggrExceptionInFinalize
self.fail("should have raised an OperationalError")
AssertionError: should have raised an OperationalError====================================================================== Traceback (most recent call last):
File "/Volumes/cache/py/main4/3x/unix/source/Lib/sqlite3/test/userfunctions.py", line 309, in CheckAggrNoFinalize
self.fail("should have raised an OperationalError")
AssertionError: should have raised an OperationalErrorRan 232 tests in 2.988s FAILED (failures=2, skipped=1) |
|
Heh, that's the kind of behavior change I was worried about :(. |
|
ned> The changes for this issue appear to have changed the behavior of test_sqlite. I don't understand why the test is failing, nor why it is only failing on one specific buildbot. Does it mean that 5/0 does not raise an exception on this specific buildbot? I don't understand the relation between my changesets and this failure. |
|
New changeset c73f4dced6aa by Victor Stinner in branch 'default': |
Ok, I found the reason in the definition of the |
|
c73f4dced6aa appears to fix the problem on 10.4 Tiger. Thanks! |
|
There is no more known bug, i'm closing this issue. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: