First of all thanks for your detailed reply! According to the documentation its
not recommended to reuse a preparedStatement after finalizing it. So my initial
guess to do something like this:
sqlite3_stmt *preparedStatement = 0;
static char command [1024];
sprintf (command, "SELECT * from model where id=?");
if (sqlite3_prepare_v2 (db, command, strlen(command), &preparedStatement, 0) !=
SQLITE_OK)
{
LOG_MESSAGE ("SQLite Error: %s error=%d\n", sqlite3_errmsg (db),
sqlite3_errcode (db));
sqlite3_finalize (preparedStatement);
return FALSE;
}
sqlite3_bind_int (preparedStatement, 1, dd.deviceIndex);
success = sqlite3_step(preparedStatement);
//read result
if ((retVal= sqlite3_finalize(preparedStatement)) != SQLITE_OK){
LOG_MESSAGE ("SQLite Error: %s error=%d\n", sqlite3_errmsg (db),
sqlite3_errcode (db));
}
else
preparedStatement=0;
sprintf (command, "SELECT * FROM type WHERE id=%d", id);
if (sqlite3_prepare_v2 (db, command, strlen(command), &preparedStatement, 0) !=
SQLITE_OK)
{
LOG_MESSAGE ("SQLite Error: %s error=%d\n", sqlite3_errmsg (db),
sqlite3_errcode (db));
sqlite3_finalize (preparedStatement);
return FALSE;
}
if ((success = sqlite3_step(preparedStatement)) != SQLITE_ROW)
{
LOG_MESSAGE ("SQLite Error: %s error=%d\n", sqlite3_errmsg (db),
sqlite3_errcode (db));
sqlite3_finalize (preparedStatement);
return FALSE;
}
//read result
sqlite3_finalize (preparedStatement);
return TRUE;
Am I right that this is not possible? So I have to use one sqlite3_stmt for
each prepare?
Best regards,
Chris.
-------- Original-Nachricht --------
> Datum: Thu, 27 Oct 2011 16:00:52 +0000
> Von: "Black, Michael (IS)" <michael.bla...@ngc.com>
> An: General Discussion of SQLite Database <sqlite-users@sqlite.org>
> Betreff: Re: [sqlite] Segmentation Fault on SQLITE3_exex
> I think we went throught something similar to this a while ago.
>
>
>
> Does each class have it's own instantiation of your database object?
>
>
>
> The way you describe it they are all using the same one.
>
>
>
> sqlite3_reset does not "clean up" -- it "resets" the statement to its
> initial state:
>
> http://www.sqlite.org/c3ref/reset.html
>
>
>
> sqlite3_finalize is what essentially "deletes" the statement and frees
> memory.
>
>
>
> You quite obviously cannot reuse a prepared statement if you only have one
> class object instantiated. They'll walk on each other.
>
>
>
> If you want to reuse a prepared statement your threads are going to have
> to maintain the statements and pass it in to your db object.
>
>
>
> But you didn't describe reusing a prepared statement. Your descriptoin
> is a memory leak as you have two prepare's without a finalize between them.
>
>
>
>
>
> Michael D. Black
>
> Senior Scientist
>
> Advanced Analytics Directorate
>
> Advanced GEOINT Solutions Operating Unit
>
> Northrop Grumman Information Systems
>
> ________________________________
> From: sqlite-users-boun...@sqlite.org [sqlite-users-boun...@sqlite.org] on
> behalf of Christian [siriu...@gmx.de]
> Sent: Thursday, October 27, 2011 10:24 AM
> To: General Discussion of SQLite Database; sqlite-users@sqlite.org
> Subject: EXT :Re: [sqlite] Segmentation Fault on SQLITE3_exex
>
> Currently I'm using valgrinds memcheck tools to solve the issue, I already
> found some undelete memory which is definitly not causing the error, but I
> receive a lot of these messages:
>
> ==13965== 1,006,200 bytes in 975 blocks are possibly lost in loss record
> 226 of 228
> ==13965== at 0x4024F20: malloc (vg_replace_malloc.c:236)
> ==13965== by 0x8096FD6: sqlite3MemMalloc (sqlite3.c:14854)
> ==13965== by 0x8097957: mallocWithAlarm (sqlite3.c:18369)
> ==13965== by 0x80979EE: sqlite3Malloc (sqlite3.c:18402)
> ==13965== by 0x809813B: sqlite3DbMallocRaw (sqlite3.c:18734)
> ==13965== by 0x809818A: sqlite3DbRealloc (sqlite3.c:18753)
> ==13965== by 0x80BAA5B: growOpArray (sqlite3.c:58415)
> ==13965== by 0x80BAAD4: sqlite3VdbeAddOp3 (sqlite3.c:58447)
> ==13965== by 0x80BAB79: sqlite3VdbeAddOp0 (sqlite3.c:58471)
> ==13965== by 0x80EF9EF: sqlite3GetVdbe (sqlite3.c:93756)
> ==13965== by 0x80F3C8E: sqlite3Select (sqlite3.c:96128)
> ==13965== by 0x8103B4D: yy_reduce (sqlite3.c:107894)
>
> A lot means 200 of them until the program crashes. You're right that I'm
> not able to show you the complete code, beside the fact that the project
> consists of different threads using sqlite3 database. Thats why I'm thinking
> that something is wrong with the setup I use, or the sqlite usage in
> general. I shortly explain what I'm doing. For timing reasons I just have one
> open
> connection to the database, which seems to be fine according the man page.
> From my main thread I give every accessing thread a pointer to the object
> which maintains all database functionality, there I always use my own
> mutexes to synchronize the access, I also tried using the set command:
> sqlite3_config (SQLITE_CONFIG_SERIALIZED) looking to the sources also tells
> me that
> it is not neccessary to set own mutexes but I guess it would not have any
> bad effect having them in there.
>
> From my database class all DB operations are performed. Could it be that
> it is not possible to reuse prepared statements what I basically do in all
> functions is:
>
> sprintf (command, "SELECT name FROM attribute WHERE
> id=%d",attributeIndex);
>
> if (sqlite3_prepare_v2 (db, command, strlen(command), &preparedStatement,
> 0) != SQLITE_OK)
> {
> sqlite3_finalize (preparedStatement);
> }
>
> sqlite3_reset(preparedStatement);
> // followed by the next prepare
> sqlite3_prepare_v2 (preparedStatement);
> sqlite3_step();
> sqlite3_reset(preparedStatement);
> sqlite3_finalize (preparedStatement);
>
>
> I guess reset is not cleaning up the statement as I supposed?
>
> Best regards,
> Chris.
>
> -------- Original-Nachricht --------
> > Datum: Thu, 27 Oct 2011 12:12:16 +0000
> > Von: "Black, Michael (IS)" <michael.bla...@ngc.com>
> > An: General Discussion of SQLite Database <sqlite-users@sqlite.org>
> > Betreff: Re: [sqlite] Segmentation Fault on SQLITE3_exex
>
> >
> >
> > Then put a breakpoint on the "p" being passed into this function to
> catch
> > when it changes....it should only change maybe once during execution
> (not
> > sure about that though).
> >
> >
> >
> > Assuming your program runs the same in debug as it does when not in
> debug
> > (which frequently changes behaviors in these situations).
> >
> >
> >
> > Your segfault may move. Matter of fact, if it doesn't change/move when
> > you add DUMA or such you may have a more systemic error on your side.
> > Usually buffer overruns or stack corruption moves under different
> compilation
> > options.
> >
> >
> >
> > You got arrays of some sort? Or char* that you are manipulating? Or
> > char[] that you are abusing? Those are the most common errors.
> >
> >
> >
> > And I guess you can't show us your code?
> >
> >
> >
> > Michael D. Black
> >
> > Senior Scientist
> >
> > Advanced Analytics Directorate
> >
> > Advanced GEOINT Solutions Operating Unit
> >
> > Northrop Grumman Information Systems
> >
> > ________________________________
> > From: sqlite-users-boun...@sqlite.org [sqlite-users-boun...@sqlite.org]
> on
> > behalf of Christian [siriu...@gmx.de]
> > Sent: Thursday, October 27, 2011 6:49 AM
> > To: General Discussion of SQLite Database; sqlite-users@sqlite.org
> > Subject: EXT :Re: [sqlite] Segmentation Fault on SQLITE3_exex
> >
> > Honestly I already expected for this kind of answer. I keep on
> debugging
> > the code using DUMA. Thanks alot for the swift response!
> >
> >
> >
> >
> > -------- Original-Nachricht --------
> > > Datum: Thu, 27 Oct 2011 10:42:37 +0000
> > > Von: "Black, Michael (IS)" <michael.bla...@ngc.com>
> > > An: General Discussion of SQLite Database <sqlite-users@sqlite.org>
> > > Betreff: Re: [sqlite] Segmentation Fault on SQLITE3_exex
> >
> > > Me thinkst you're corrupting your stack or memory.
> > >
> > >
> > >
> > > I'd be willing to bet big money that this is your program causing this
> > as
> > > there are 1000's of people running that exact same call without any
> > problem
> > > at all (like me and I've been using it like crazy across multiple
> > versions
> > > of SQLite)
> > >
> > >
> > >
> > > If you can try using something like efence which may help detect it.
> I
> > > assume you're on a Unix flavor?
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > Michael D. Black
> > >
> > > Senior Scientist
> > >
> > > Advanced Analytics Directorate
> > >
> > > Advanced GEOINT Solutions Operating Unit
> > >
> > > Northrop Grumman Information Systems
> > >
> > > ________________________________
> > > From: sqlite-users-boun...@sqlite.org
> [sqlite-users-boun...@sqlite.org]
> > on
> > > behalf of Christian [siriu...@gmx.de]
> > > Sent: Thursday, October 27, 2011 4:51 AM
> > > To: sqlite-users@sqlite.org
> > > Subject: EXT :[sqlite] Segmentation Fault on SQLITE3_exex
> > >
> > > Hello everybody,
> > >
> > > I'm facing a strange issue and believe that my setup is somehow wrong.
> > > From time to time my program crashes with segfault when calling:
> > > if (sqlite3_exec (db, "BEGIN TRANSACTION", 0, 0, 0) != SQLITE_OK)
> > > {
> > > //error
> > > }
> > >
> > > The stacktrace points to this function:
> > >
> > > static void pthreadMutexEnter(sqlite3_mutex *p){
> > > assert( p->id==SQLITE_MUTEX_RECURSIVE || pthreadMutexNotheld(p) );
> > >
> > > #ifdef SQLITE_HOMEGROWN_RECURSIVE_MUTEX
> > > {
> > > pthread_t self = pthread_self();
> > > if( p->nRef>0 && pthread_equal(p->owner, self) ){
> > > p->nRef++;
> > > }else{
> > > pthread_mutex_lock(&p->mutex);
> > > assert( p->nRef==0 );
> > > p->owner = self;
> > > p->nRef = 1;
> > > }
> > > }
> > > #else
> > > /* Use the built-in recursive mutexes if they are available.
> > > */
> > > pthread_mutex_lock(&p->mutex); //!HERE IT GETS a SEGFAULT!
> > > #if SQLITE_MUTEX_NREF
> > > assert( p->nRef>0 || p->owner==0 );
> > > p->owner = pthread_self();
> > > p->nRef++;
> > > #endif
> > > }
> > >
> > >
> > > Any ideas why this happens, or how I could workaround the issue? The
> > query
> > > works like 300 times and then suddenly crashes, I checked this with
> > > version 3.6.22 (as library) and the actual sources (3.7.8 _ 3007008).
> > >
> > > Best regards,
> > > Chris.
> > > --
> > > NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie!
> > > Jetzt informieren: http://www.gmx.net/de/go/freephone
> > > _______________________________________________
> > > sqlite-users mailing list
> > > sqlite-users@sqlite.org
> > > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
> > > _______________________________________________
> > > sqlite-users mailing list
> > > sqlite-users@sqlite.org
> > > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
> >
> > --
> > Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
> > belohnen Sie mit bis zu 50,- Euro!
> >
> https://freundschaftswerbung.gmx.de<https://freundschaftswerbung.gmx.de/<https://freundschaftswerbung.gmx.de%3chttps//freundschaftswerbung.gmx.de/>>
> > _______________________________________________
> > sqlite-users mailing list
> > sqlite-users@sqlite.org
> > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
> > _______________________________________________
> > sqlite-users mailing list
> > sqlite-users@sqlite.org
> > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>
> --
> Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
> belohnen Sie mit bis zu 50,- Euro!
> https://freundschaftswerbung.gmx.de<https://freundschaftswerbung.gmx.de/>
> _______________________________________________
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
> _______________________________________________
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
--
NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie!
Jetzt informieren: http://www.gmx.net/de/go/freephone
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
