On 12/20/15, Jonathan Metzman <jon.metzman at gmail.com> wrote:
> When fuzzing with AFL, I found that running the commands below on the
> sqlite shell (sqlite-amalgamation-201511301915.zip) results in the
> assertion failure: "sqlite3.c:89394: int sqlite3ExprCompare(Expr *, Expr *,
> int): Assertion `0' failed."
>
> The crashing input:
>
> CREATE TABLE t0(a,b,t);
> CREATE INDEX i ON t0(a in(0,0));
> INSERT INTO t0 VALUES(0,0,0);
> UPDATE t0 SET b=0 WHERE a in(0,0)=0;
>
> Running the same case without assertions on doesn't seem to cause a crash
> of any kind. I also tried running it without assertions and with asan/msan
> and there was no crash there either.
>
Yeah - it is not dangerous. The "assert()" was in fact the NEVER()
macro on this line:
https://www.sqlite.org/src/artifact/ccb93d7b7e?ln=3841
The macro NEVER(x) normally expands to just x. It means that, as far
as the developers know, the boolean x is always false. Or, to put it
another way, we have previously been unable to find a test case for
which the boolean is true.
When compiled with -DSQLITE_DEBUG, the NEVER() macro will cause an
assertion fault if the boolean is true. That is what you are seeing.
That means you found a test case for us! Thanks!
Lots of analysis will follow, as we try to figure out why this test
case was missed. (Probably it is because the case is only reachable
when using indexes on expresssions, which is a recently added
feature.) Watch the timeline (https://www.sqlite.org/src/timeline)
for a simple fix which will likely be added later this morning.
--
D. Richard Hipp
drh at sqlite.org
