|
2019-02-08
| ||
| 14:59 | Merge the fix for ticket [4e8e4857d32d401f], so that this branch now contains release 3.27.1 plus the extra patch to preserve ROWID values on VACUUM. (check-in: 0cdae60e user: drh tags: apple-osx) | |
| 12:46 | Cherrypick the fix for ticket [4e8e4857d32d401f] from trunk. (check-in: d5d944d7 user: drh tags: branch-3.27) | |
| 04:20 | • Fixed ticket [4e8e4857]: Crash on query using an OR term in the WHERE clause plus 6 other changes (artifact: f29e381b user: drh) | |
| 04:15 | Do not do the optimization that attempts to pull expression values from an index on that expression when processing a multi-index OR (see check-in [a47efb7c8520a0111]) because the expression transformations that are applied become invalid when the processing moves off of the current index and on to the next index. Fix for ticket [4e8e4857d32d401f]. (check-in: 440a7cda user: drh tags: trunk) | |
| 03:01 | • New ticket [4e8e4857] Crash on query using an OR term in the WHERE clause. (artifact: 006561ff user: drh) | |
| 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:
The query at the end of the following SQL crashes due to a NULL pointer dereference. 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; 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: 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. | ||||