On Mon, 31 Jan 2011 18:08:41 -0500, Ralf Junker <ralfjun...@gmx.de> wrote:

> This SQL:
>
>   drop table if exists t11;
>   CREATE VIRTUAL TABLE t11 USING fts4;
>   INSERT INTO t11 VALUES('quitealongstringoftext');
>   INSERT INTO t11 VALUES('anotherquitealongstringoftext');
>   UPDATE t11_stat SET value = X'0000';

I actually think this is a documentation bug/failure-to-warn liability:

        WARNING:  Deliberately junking FTS’ internal tables may
        not only corrupt your FTS table, but also cause SQLite
        to crash.  Don’t do this.  Also do not use the hair dryer
        while in the bathtub, attempt to stop the chainsaw’s chain
        with your hand, &c.  Inserting peanuts into your SQLite
        database may cause it to contain nuts.

Please add to FTS docs §6 so you can avoid being sued.

>   SELECT matchinfo(t11, 'nxa') FROM t11 WHERE t11 MATCH 'a*';
>
> leads to a division by zero exception in fts3_snippet.c, line 1171:
>
>   pInfo->aMatchinfo[iCol] =  
> (u32)(((u32)(nToken&0xffffffff)+nDoc/2)/nDoc);
>
> nDoc is zero here, which is not tested for, but I believe it should.
>
> Ralf

Does the crash also occur when the zero occurs naturally, or is that  
codepath not exercised?  Perhaps an assert() is in order.

Very truly,

Samuel Adam <a...@certifound.com>
763 Montgomery Road
Hillsborough, NJ  08844-1304 • United States
http://certifound.com/
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Reply via email to