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.
