2017-08-01
| ||
19:53 | • Fixed ticket [cb91bf42]: Assertion fault following PRAGMA reverse_unordered_selects=ON plus 5 other changes (artifact: 1e861ce0 user: drh) | |
19:53 | Split the OP_Last opcode into OP_Last and OP_SeekEnd. Use OP_SeekEnd to position a cursor prior to appending. Ticket [cb91bf4290c211d]. (check-in: 3e02474c user: drh tags: trunk) | |
18:21 | • New ticket [cb91bf42] Assertion fault following PRAGMA reverse_unordered_selects=ON. (artifact: b9784104 user: drh) | |
Ticket Hash: | cb91bf4290c211de24389bcefd8a06d56c099d9f | |||
Title: | Assertion fault following PRAGMA reverse_unordered_selects=ON | |||
Status: | Fixed | Type: | Code_Defect | |
Severity: | Minor | Priority: | Immediate | |
Subsystem: | Unknown | Resolution: | Fixed | |
Last Modified: | 2017-08-01 19:53:54 | |||
Version Found In: | 3.20.0 | |||
User Comments: | ||||
drh added on 2017-08-01 18:21:15:
When assert()s are enabled (which is to say when SQLite is compiled using -DSQLITE_DEBUG) the following SQL causes an assertion fault in the byte-code engine: PRAGMA reverse_unordered_selects=on; CREATE TABLE t1(a,b); INSERT INTO t1 VALUES(1,2); CREATE INDEX t1b ON t1(b); SELECT a FROM t1 WHERE b=-99 OR b>1; Bisecting shows that this bug was introduced with check-in [663473850c] on 2016-11-15 and first appeared in release 3.16.0. As far as we can determine at this time, the bug is harmless in the sense that SQLite functions normally and computes the correct answer when assert()s are disabled. However, the assertion fault does indicate that the logic is confused and needs to be refactored for long-term maintainability. This problem was discovered by OSSFuzz. |