Hello !
I was calling sqlite3_close_v2 after sqlite3_next_stmt/sqlite3_finalize the
problem probably was the fts3/4 extension trying to finalize a statement I
already had finalized.
Cheers !
> Fri Sep 04 2015 5:42:03 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 10:13 PM, Domingo Alvarez Duarte wrote:
>
>>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.
>>
> The trouble with sqlite3_close_v2() is that after you call it you can't
> safely pass the db handle to sqlite3_next_stmt() - the data structure
> may have already been freed.
>
> Dan.
>
>
>
>
>
>>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
>>
> _______________________________________________
> sqlite-users mailing list
> sqlite-users at mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>
>
>
?
