On Mon, 2007-01-08 at 16:03 -0800, Peter James wrote:
> Hey folks...
>
> The context of this message is sqlite library version 3.3.6, using the
> shared-cache mode, effectively following the test_server.c example.
> Immediately upon switching to shared-cache mode we started seeing errors
> like so when preparing statements:
>
> [ERROR] (lib/sqlite/src/build.c:1220) no such collation sequence: <random
> garbage>
>
> Drilling down, this is what I'm understanding to be the case... Collators
> are attached to the individual sqlite* handles, remaining valid only while
> the connection to which the handle refers is valid. On the other hand, it
> appears that indexes are stored inside of the schema, and use a lookup
> string ("BINARY", "NOCASE") to find the contained column collators. This
> lookup string is actually in memory allocated as part of the collator, and
> is freed when the connection is closed, leaving a dangling pointer in the
> index.
This only happens with the default collation sequence. In build.c, a
pointer may be copied from sqlite3.pDfltColl->zName into the schema.
This is a bug, for the reasons identified above. (in cvs sources:
line 2479 of build.c).
But it looks to me like commit #3341 (August 2006) covers this up. #3341
changes things so that the shared-schema is reset whenever any
connection handle is closed, so it's not possible for the pointer in
question to go stale.
So if you upgrade to 3.3.7 or newer you should be Ok. Or if you can't
upgrade for your own reasons, maybe add something similar to #3341
(only one line).
Dan.
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
