SQLite

View Ticket
Login
2020-04-03
13:29
Fix a case when a pointer might be used after being freed in the ALTER TABLE code. Fix for [4722bdab08cb1]. (check-in: 52f800fa93 user: drh tags: branch-3.31)
11:26 Fixed ticket [4722bdab08]: Another renameTokenCheckAll() fault plus 5 other changes (artifact: 9ea5881e85 user: drh)
11:20
Fix a case when a pointer might be used after being freed in the ALTER TABLE code. Fix for [4722bdab08cb1]. (check-in: d09f8c3621 user: dan tags: trunk)
2020-04-02
22:55 New ticket [4722bdab08] Another renameTokenCheckAll() fault. (artifact: 2c14577f7e user: drh)

Ticket Hash: 4722bdab08cb14546924f8ea44cf77fac1bffab0
Title: Another renameTokenCheckAll() fault
Status: Fixed Type: Code_Defect
Severity: Minor Priority: Low
Subsystem: Unknown Resolution: Fixed
Last Modified: 2020-04-03 11:26:37
5.05 years ago
Created: 2020-04-02 22:55:07
5.05 years ago
Version Found In: 3.31.1
User Comments:
drh added on 2020-04-02 22:55:07:
Henry Liu of Shenzhen Ankki Technologies Co.Ltd. sent in the following script
which causes a fault in the renameTokenCheckAll() routine:

<blockquote><verbatim>
CREATE TABLE a(a);
CREATE VIEW b AS SELECT(SELECT *FROM c JOIN a USING(d, a, a, a) JOIN a) IN();
ALTER TABLE a RENAME a TO e;
</verbatim></blockquote>

Henry reports that this asserts, but I only see failures if I run under valgrind.
Note that fault is in the error-checking routine renameTokenCheckAll().  That
routine only runs in debugging mode.  For release builds, this routine is
a no-op and so the fault never occurs.