Hello ! I did something similar to your sugestion (sqlite3_next_stmt(db, NULL))? and it still segfaults.
What you mention about fts3/4 having prepared statemtns that and somehow I'm doing a double free a good point. And will be sad to not be able to use sqlite3_next_stmt(db, NULL) to finalize any open preapred statemnt, because it's very handy when using "exceptions" and having a single point to do the cleanup. Can somehow sqlite3_prepare somehow have any extra parameter to indicated that we are using it from an extension and somehow sqlite3_next_stmt detect it and skip it ? Or any way to safely have a central point to do a cleanup ? Cheers ! > Fri Sep 04 2015 4:44:02 pm CEST CEST from "Dan Kennedy" ><danielk1977 at gmail.com> Subject: Re: [sqlite] SQLite3 trunk error with old >database with fts3/4 > > On 09/04/2015 09:29 PM, Domingo Alvarez Duarte wrote: > >>Hello again ! >> >> On mac os x some time ago I was getting segfaults here and tought that it >>was >> caused by the way os x manage memory but it doesn't seem correct. >> >> The error happens on this code that is called before call sqlite3_close: >> >> sqlite3 *db = sdb->db; >> sqlite3_stmt* statement = NULL; >> int count = 0; >> while ((statement = sqlite3_next_stmt(db, statement))) >> { >> //do no close statements because garbage collector will >> do it >> //on MacOSX we get segfaults finalizing statements here >> printf("sq_sqlite3_close_release:stmt:%s\n", >> sqlite3_sql(statement)); >> sqlite3_finalize(statement); >> count++; >> } >> if (count) return sq_throwerror(v, _SC("closing database with >> %d statements not closed."), count); >> > Hi, > > Two problems: > > After you have finalized a statement handle, it may not be passed to > sqlite3_next_stmt(). Change the while() line to: > > while( (statement = sqlite3_next_stmt(db, NULL)) ){ ... > > Another reason not to do this before calling sqlite3_close() is that the > FTS module may be managing some of these statement handles. So if you > finalize() them before sqlite3_close() is called, then when the FTS > module is shut down as part of the eventual sqlite3_close() call, it may > pass the same statement handle pointers to sqlite3_finalize() - similar > to a double-free of any other object or memory allocation. SQLite > includes checks to try to return SQLITE_MISUSE instead of crashing when > this happens, but they only work some of the time - this scenario can > still cause crashes or heap corruption. > > A workaround is to call sqlite3_close() on the db, then do the above > only if it returns SQLITE_BUSY. This works because, even though it > fails, the first sqlite3_close() shuts down the FTS module - > guaranteeing that it is no longer holding pointers to statement handles. > > Even better is not to leak statement handle pointers. The > sqlite3_next_stmt() API should really only be used to help track down > leaks, not to do cleanup. > > Dan. > > > > > > > > > > >> >>>Fri Sep 04 2015 4:18:01 pm CEST CEST from "Domingo Alvarez Duarte" >>> <sqlite-mail at dev.dadbiz.es> Subject: Re: [sqlite] SQLite3 trunk error >>>with >>> old database with fts3/4 >>> >>> Hello ! >>> >>> I'm not sure where the problem is but this code worked without any >>>problem >>> with previous sqlite3. >>> >>> Here is a backtrace of a segfault using gdb (the line numbers will not >>> match >>> standard sqlite3.c because I have some custom extensions): >>> >>> enter mutex 0x7fffe405f570 (1213663847) with nRef=1919906927 >>> >>> Program received signal SIGSEGV, Segmentation fault. >>> [Switching to Thread 0x7ffff3c70700 (LWP 22336)] >>> 0x0000000000479d85 in freeEphemeralFunction (db=0x7fffe4000078, >>> pDef=0xaaaaaaaaaaaaaaaa) >>> at sqlite3.c:66869 >>> 66869 if( ALWAYS(pDef) && (pDef->funcFlags & SQLITE_FUNC_EPHEM)!=0 >>> ){ >>> (gdb) bt >>> #0 0x0000000000479d85 in freeEphemeralFunction (db=0x7fffe4000078, >>> pDef=0xaaaaaaaaaaaaaaaa) >>> at sqlite3.c:66869 >>> #1 0x0000000000479e39 in freeP4 (db=db at entry=0x7fffe4000078, >>> p4type=-1431655766, p4=0x7fffe4181588) >>> at sqlite3.c:66884 >>> #2 0x0000000000479f14 in vdbeFreeOpArray (db=0x7fffe4000078, >>> aOp=0x7fffe40df508, nOp=<optimised out>) >>> at sqlite3.c:66933 >>> #3 0x000000000047a01c in sqlite3VdbeClearObject (db=0x7fffe4000078, >>> p=0x7fffe408ac88) at sqlite3.c:68920 >>> #4 0x000000000047a0c3 in sqlite3VdbeDelete (p=0x7fffe408ac88) >>> at sqlite3.c:68941 >>> #5 0x00000000004e6044 in sqlite3VdbeFinalize (p=0x7fffe408ac88) >>> at sqlite3.c:68861 >>> #6 0x00000000004e60cd in sqlite3_finalize (pStmt=0x7fffe408ac88) >>> at sqlite3.c:70500 >>> >>> >>> >>> >>>>Fri Sep 04 2015 4:05:12 pm CEST CEST from "Dan Kennedy" >>>> <danielk1977 at gmail.com> Subject: Re: [sqlite] SQLite3 trunk error with >>>>old >>>> database with fts3/4 >>>> >>>> On 09/04/2015 07:35 PM, Domingo Alvarez Duarte wrote: >>>> >>>> >>>> >>>>>Hello ! >>>>> >>>>> After fix the index issues using an old sqlite3 executable (the trunk >>>>> refuse >>>>> to work on indexes created with single quotes on field names) I'm >>>>>getting >>>>> ocasionaly memory errors when using fts3/4 searches, see error below: >>>>> >>>>> free(): corrupted unsorted chunks: 0x00007fa3a01073a0 >>>>> >>>>> >>>> Is this error on the trunk or with the old version? >>>> >>>> If it's on the trunk, is the error reproducible using the sqlite3 shell >>>> tool? >>>> >>>> If not, what does valgrind have to say about the app? >>>> >>>> Thanks, >>>> Dan. >>>> >>>> _______________________________________________ >>>> sqlite-users mailing list >>>> sqlite-users at mailinglists.sqlite.org >>>> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>> _______________________________________________ >>> sqlite-users mailing list >>> sqlite-users at mailinglists.sqlite.org >>> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users >>> >>> >>> >>> >>> >>> >> _______________________________________________ >> sqlite-users mailing list >> sqlite-users at mailinglists.sqlite.org >> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users >> > _______________________________________________ > sqlite-users mailing list > sqlite-users at mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users > > > ?