Hello !
As I said before the problem is in this code (I suspect that finalizing the
statement inside a loop using sqlite3_next_stmt(db, statement) is the
problem):
??????? 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: %p : %s\n",
statement, sqlite3_sql(statement));
??????????? sqlite3_finalize(statement);
??????????? count++;
??????? }
?
> Fri Sep 04 2015 4:33:13 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:18 PM, Domingo Alvarez Duarte wrote:
>
>>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):
>>
> Extensions in the sense that the core SQLite code has been enhanced? Or
> extensions as in code that interacts with SQLite using only APIs that
> begin with "sqlite3_"?
>
> If you run the app under valgrind are there any interesting errors or
> warnings?
>
>
>
>>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
>>
> It's tricky to interpret this. It seems likely that the pDef pointer in
> the last frame might be incorrect - or that might just be an artifact of
> optimization.
>
> Thanks,
> Dan.
>
> _______________________________________________
> sqlite-users mailing list
> sqlite-users at mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>
>
>
?
