Hello again ! I think that would be interesting to have functions similar to sqlite3_next_stmt/sqlite3_finalize for extensions something like this:
sqlite3_next_extension / sqlite3_finalize_extension ? Cheers ! > Fri Sep 04 2015 5:13:23 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 again ! > > I looked at the documentaion again and realized that I was alread calling > sqlite3_close_v2 the I commented out all of the sqlite3_next_stmt cleanup >and > no segfaults so far, I'll see if memory is released on a long running >process > to certify that everything is fine. > > Thanks a lot for your help ! > > > > >>Fri Sep 04 2015 4:57:57 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 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 >>> >>> >>> >>> >>> >>> >>> >> ? >> _______________________________________________ >> 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 > > > ?