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
