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