On 3/6/62 12:51, bhandari_nikhil wrote:
I am facing a crash in sqlite3fts5BufferAppendBlob. Following is the
backtrace:
#0 sqlite3Fts5BufferAppendBlob (pRc=pRc@entry=0xf54139c8,
pBuf=pBuf@entry=0xf5afeb90, nData=4294967295, pData=0xf49fff76 "90246ture")
at sqlite3.c:180474
#1 0xf717b6f8 in fts5WriteAppendTerm (p=p@entry=0xf54139a8,
pWriter=pWriter@entry=0xf5afeb84, nTerm=5, pTerm=0xf49fff70
"06280290246ture") at sqlite3.c:188868
#2 0xf717bf29 in fts5IndexMergeLevel (p=p@entry=0xf54139a8,
ppStruct=ppStruct@entry=0xf5afec3c, iLvl=3, pnRem=0xf5afec38) at
sqlite3.c:189176
There is an apparent bug in sqlite3fts5BufferAppendBlob where it is
asserting for check on nData < 0 but nData is actually u32. The nData should
be int, not u32. I am using version 3.14.0.100 but the bug is present in the
latest version as well.
Also, if you notice in frame #0, the nData passed is 0xffffffff which is -1.
It was calculated to be -1 in frame #1 where it did nTerm - nPrefix. The
nPrefix value came out to be 6 and nTerm was 5. I want to know when this
nPrefix becomes > nTerm ?
Thanks for reporting this.
I think that can only happen if the FTS5 records stored in the database
are corrupt. If you are able to share the database I can check for you.
You can probably repair the index using the following:
https://sqlite.org/fts5.html#the_rebuild_command
Also, I would have thought this crash would have been fixed by this
change, which is in 3.28.0:
https://sqlite.org/src/info/673a7dd698
Have you demonstrated the crash with the latest version, or just
eyeballed the code?
Cheers then,
Dan.
Regards
Nikhil Bhandari
--
Sent from: http://sqlite.1065341.n5.nabble.com/
_______________________________________________
sqlite-users mailing list
[email protected]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
_______________________________________________
sqlite-users mailing list
[email protected]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
