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: 52f800fa user: drh tags: branch-3.31) | |
11:26 | • Fixed ticket [4722bdab]: Another renameTokenCheckAll() fault plus 5 other changes (artifact: 9ea5881e 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: d09f8c36 user: dan tags: trunk) | |
2020-04-02
| ||
22:55 | • New ticket [4722bdab] Another renameTokenCheckAll() fault. (artifact: 2c14577f 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 | |||
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: 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; 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. |