BTW apsw does handle exceptions in collation functions (it
is mentioned in the doc).
It looks like this is actually a bug in SQLite. I am still
digging, but pointing fingers at this trace in SQLite 3.2.7
code:
==2378== Conditional jump or move depends on uninitialised value(s)
==2378== at 0x1BE9E175: sqlite3VdbeMemRelease (vdbemem.c:220)
==2378== by 0x1BE9E556: sqlite3VdbeMemSetStr (vdbemem.c:416)
==2378== by 0x1BE9AC17: sqlite3_result_error (vdbeapi.c:96)
==2378== by 0x1BE8E47C: cbdispatch_step (apsw.c:1311)
==2378== by 0x1BEC9351: sqlite3VdbeExec (vdbe.c:4250)
==2378== by 0x1BE9AF49: sqlite3_step (vdbeapi.c:217)
==2378== by 0x1BE90485: Cursor_step (apsw.c:2252)
==2378== by 0x1BE90A70: Cursor_execute (apsw.c:2445)
==2378== by 0x1B96DB3A: PyCFunction_Call (in /usr/lib/libpython2.3.so.1.0)
The apsw.c:1311 code is telling sqlite there is an error and it looks
like sqlite tries to generate an error code string and tries to free
a bogus pointer to do so.
Roger
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]