SQLite: View Ticket

2011-03-24
01:34		The changes to fix [f7b4edece25c9948] mean that the schema is always loaded whenever a prepared statement is running. This means that a couple of branches can be eliminated and one operand of OP_ParseSchema can be removed. (check-in: b6e268fce1 user: drh tags: trunk)
2011-03-19
02:37		Merge the fix to ticket [f7b4edece25c99485] into the sessions branch. (check-in: 1b736ac293 user: drh tags: sessions)
02:04		• Fixed ticket [f7b4edece2]: sqlite3_update_hook gives incorrect table name with shared cache plus 2 other changes (artifact: 45ac238b90 user: drh)
02:04		Add a test case to verify that ticket [f7b4edece25c994857] is fixed. (check-in: eedbcf0a0b user: drh tags: trunk)
2011-03-18
21:55		Add a generation counter to the Schema object and enhance OP_VerifySchema to also check the Schema generation. Fix for ticket [f7b4edece25c99]. (check-in: 36c04dd169 user: drh tags: trunk)
18:55		• New ticket [f7b4edece2] sqlite3_update_hook gives incorrect table name with shared cache. (artifact: 126604a626 user: drh)

Ticket Hash:	f7b4edece25c994857dc139207f55a53c8319fae
Title:	sqlite3_update_hook gives incorrect table name with shared cache
Status:	Fixed	Type:	Code_Defect
Severity:	Critical	Priority:	Immediate
Subsystem:	Unknown	Resolution:	Fixed
Last Modified:	2011-03-19 02:04:24 14.30 years ago	Created:	2011-03-18 18:55:48 14.30 years ago
Version Found In:	3.7.5

Description:

The fourth argument to the sqlite3_update_hook() callback is suppose to be the name of the table that is being updated. However, this string pointer might point to deallocated memory if shared cache mode is in use. Here is the scenario:

Two connections to the same database (call them A and B) in shared cache mode.
Connection A prepares a statement that will invoke the update hook.
Connection B makes a schema change but rolls back before committing.
Connection A evaluates the prepared statement.

The prepared statement in step (2) contains a pointer to the table name string in the parsed schema. Step (3) causes the schema to be reparsed, which invalidates that string. But the rollback of step (3) means that the schema cookie is unchanged and so the prepared statement is not invalidated. Step (4) then runs the prepared statement and passes the invalid string to the update hook callback.

This problem was found by internal code review and has never been observed in the wild.