SQLite

View Ticket
Login
Ticket Hash: 4e8e4857d32d401f261048ee2686f1d9f7877814
Title: Crash on query using an OR term in the WHERE clause
Status: Fixed Type: Code_Defect
Severity: Severe Priority: Immediate
Subsystem: Unknown Resolution: Fixed
Last Modified: 2019-02-08 04:20:21
Version Found In: 3.27.0
User Comments:
drh added on 2019-02-08 03:01:59: (text/x-fossil-wiki)
The query at the end of the following SQL crashes due to a NULL pointer
dereference.

<blockquote><verbatim>
CREATE TABLE t1(aa, bb);
CREATE INDEX t1x1 on t1(abs(aa), abs(bb));
INSERT INTO t1 VALUES(-2,-3),(+2,-3),(-2,+3),(+2,+3);
SELECT * FROM (t1) 
 WHERE ((abs(aa)=1 AND 1=2) OR abs(aa)=2)
   AND abs(bb)=3;
</verbatim></blockquote>

This ticket derives from a separate ticket that was reported against
System.Data.SQLite:
[https://system.data.sqlite.org/index.html/info/b0778fcc041fdca4]

Bisecting shows that the problem was introduced for SQLite version
3.20.0 (2017-08-01) by check-in [712267c9c08fdcef] (2017-06-23).

drh added on 2019-02-08 04:20:21: (text/x-fossil-wiki)
The real problem here is in the optimization of check-in [a47efb7c8520a0111]
that tries to make use of expression values pulled from columns of an
expression index, rather than recomputing the value of the expression.
When processing a multi-index OR clause, the transformations on the expressions
to convert them from their original expressions into a reference to the index
column become invalid when processing moves on to the next index of a multi-index
OR.  The solution is to simply disable that optimization for a multi-index OR.

The optimization at [712267c9c08fdcef] that was found by bisect is blameless
here, I think.  That optimization merely enabled this particular test case
to work, and was not the underlying cause of the problem.