SQLite

View Ticket
Login
2015-04-28
12:44
Shift the Mem.pScopyFrom pointer in the correct direction in OP_Move. Fix for a defective check-in [a2135ad13049] and ticket [d6352363751]. Debugging code only - does not affect normal operation. (check-in: add4e043b3 user: drh tags: trunk)
2011-09-19
17:37 Closed ticket [d635236375]: Assertion fault on a join with a repeated column (artifact: 32d3d34282 user: drh)
2011-08-03
16:40 Fixed ticket [d635236375]. (artifact: 852716c722 user: drh)
16:40
Update the OP_Move opcode to shift the pScopyFrom pointer of aliases when compiled with SQLITE_DEBUG. Ticket [d63523637517386191]. (check-in: a2135ad130 user: drh tags: trunk)
16:33 New ticket [d635236375] Assertion fault on a join with a repeated column. (artifact: 5cf0cd24c8 user: drh)

Ticket Hash: d63523637517386191d634eaa71de2c7ecf1e96e
Title: Assertion fault on a join with a repeated column
Status: Closed Type: Code_Defect
Severity: Minor Priority: Immediate
Subsystem: Unknown Resolution: Fixed
Last Modified: 2011-09-19 17:37:47
13.81 years ago
Created: 2011-08-03 16:33:42
13.94 years ago
Version Found In: 3.7.7
Description:
When SQLite is compiled with -DSQLITE_DEBUG, an assert() fault occurs when the following SQL is run:
   CREATE TABLE t1(id1 INTEGER PRIMARY KEY);
   INSERT INTO t1 VALUES(9999);
   CREATE TABLE t2(id2 INTEGER PRIMARY KEY);
   INSERT INTO t2 VALUES(12345);
   INSERT INTO t2 VALUES(54321);
   SELECT count(*) FROM t1, t2 GROUP BY id1, id1;

The failing assert() is checking to ensure that when a "shallow copy" of a value is used, that the original hard copy of the object that the shallow copy is pointing to is unchanged from when the shallow copy was first made. In this case, both the shallow copy and the original are moving together, though, so the assertion fault does not indicate a real malfunction. The work-around is to not compile with SQLITE_DEBUG. A proper fix is forthcoming.