I stand corrected, thank you Andrew. I seriuosly doubt it is a bug in
SQlite, but I have had a hell of a time with sqlite and binding
dynamically allocated text and binary data.
On 7/1/07, Andrew Finkenstadt <[EMAIL PROTECTED]> wrote:
On 7/1/07, Rich Rattanni <[EMAIL PROTECTED]> wrote:
>
> I was trying to look through the SQLITE source code to see how the
> sqlite3_bind_blob routine worked.
>
> sqlite3_bind_blob passes the data pointer to bindText
> bindText passes the data pointer to sqlite3VdbeMemSetStr
> sqlite3VdbeMemSetStr then does...
> ...
> pMem->z = (char *)z;
> if( xDel==SQLITE_STATIC ){
> pMem->flags = MEM_Static;
> }else if( xDel==SQLITE_TRANSIENT ){
> pMem->flags = MEM_Ephem;
> }else{
> pMem->flags = MEM_Dyn;
> pMem->xDel = xDel;
> }
> ...
>
> I dont see anywhere where sqlite3 copies data to a private buffer, I
> just see where sqlite3 saves a copy of the user pointer.
>
Further down in that function, after setting MEM_Ephem, there are these
lines of code:
if( pMem->flags&MEM_Ephem ){
return sqlite3VdbeMemMakeWriteable(pMem);
}
which does the memory copy when SQLITE_TRANSIENT is used as a side-effect of
making it "writable".
In your original outline you issued sqlite3_step before freeing the memory.
If you leave it that way, you can get away with SQLITE_STATIC when binding
the blob... which might indicate something by whether/where the crash still
occurs.
--andy
just a sqlite user, not really a knower-of-code
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
