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
