SET STATEMENT <var=val> FOR <query> causes crash when plugin reallocates dynamic string thread variable memory
Affects | Status | Importance | Assigned to | Milestone | ||
---|---|---|---|---|---|---|
Percona Server moved to https://jira.percona.com/projects/PS | Status tracked in 5.7 | |||||
5.6 |
Triaged
|
Low
|
Unassigned | |||
5.7 |
Triaged
|
Low
|
Unassigned |
Bug Description
- Both TokuDB and TokuBackupPlugin define and use a MYSQL_THDVAR_STR to report/hold some status information. In TokuDB it is tokudb_
- These variable manage their own memory, meaning that when modified by either a user executing a 'SET <variable>=' or from some internal action, they free and reallocate their buffer that is holding their content.
Consider this sequence:
1. DROP DATABASE test;CREATE DATABASE test;USE test;
2. CREATE TABLE t(a INT,b INT,c BINARY(1),d BINARY (1),e VARBINARY(1),f VARBINARY(1),g BLOB,h BLOB,id INT,KEY(
3. CREATE TABLE t1(a INT KEY,b CHAR (1),c VARCHAR(1)) ENGINE=TokuDB;
4. XA START 'xid1','br_1';
5. SET @a :=(SELECT COUNT(*)FROM t1);
6. SET GLOBAL table_open_cache=3;
7. select concat('From JSON subselect ',c,' as DATE'),cast((select a from t where c='opaque_
8. SELECT * FROM t1;
9. SET STATEMENT sort_buffer_
10. select count(*)from t1 where MBRIntersects(
If the statement on line 9 above encounters a lock timeout, it frees the old tokudb_
The crash occurs on line 10 because now the tokudb_
Related upstream issue: https:/
Original TokuDB report: https:/
From a private email discussion with Laurynas:
"Yes, I think this is a bug in SET STATEMENT. It should either update the variable properly (maybe something like
plugin_
Workarounds for those encountering this crash:
- For tokudb_
- For tokudb_
tags: | added: set-statement |
Percona now uses JIRA for bug reports so this bug report is migrated to: https:/ /jira.percona. com/browse/ PS-2136