On Mon, 2007-07-02 at 08:51 -0400, Rich Rattanni wrote:
> I think I am incorrectly using the API, which may be leading to my
> segmentation fault...
>
> I have a variable amount (22k -> 1MB) of data, split across several
> blobs to insert into a database. I transactify the process to save
> some time (alot by my tests).
>
> sqlite3_exec(db, "BEGIN IMMEDIATE", NULL, NULL, NULL);
> -For each blob...
> sqlite3_prepare(db, "INSERT INTO table1 (blobData) VALUES (?1)", -1,
> &stmt, NULL);
> sqlite3_bind_blob(stmt, 1, blobData, blobSize, SQLITE_TRANSIENT);
> sqlite3_step(stmt); // with appropriate error checking
> sqlite3_finalize(stmt);
> -end for each.
> sqlite3_exec(db, "COMMIT", NULL, NULL, NULL);
>
> Is this incorrect? What I feel may be incorrect is the fact that I am
> finalizing the stmt before the commit. I programmed this way because
> I did not want to have a separate stmt for each INSERT. But I was
> wondering if the finalize is destroying copy of the blob data sqlite
> made during the call to sqlite3_bind_blob().
That looks fine. After the sqlite3_step() executes, SQLite has
modified the pager cache to store the inserted blob. The
statement handle may be finalized or reset at this point - the
insert has already happened.
Have you tried running valgrind or similar? Heap corruption can
result in mysterious behaviour, and shifting lines of code around
(like interchanging the free() and COMMIT ops) can sometimes make
the symptoms go away.
Dan.
> --
> Rich Rattanni
>
> On 7/1/07, Rich Rattanni <[EMAIL PROTECTED]> wrote:
> > 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]
> -----------------------------------------------------------------------------
>
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
