After several hours of hacking reducer.sh to use SOURCE (thanks Ramesh!) and reducer-script-handholding, we finally have a good/short testcase for this bug!
===============
DROP DATABASE transforms;CREATE DATABASE transforms;DROP DATABASE test;CREATE DATABASE test;USE test;
CREATE TABLE `t100_innodb_tokudb_small` (
`c17` text CHARACTER SET latin1,
key (`c17` (1))) ENGINE=innodb ROW_FORMAT=tokudb_small;
SET AUTOCOMMIT=OFF;
FLUSH TABLES `t100_innodb_tokudb_small` FOR EXPORT;
LOCK BINLOG FOR BACKUP;
UNLOCK TABLES;
UNLOCK BINLOG;
UPDATE LOW_PRIORITY `t100_innodb_compressed` SET `c9`='2001-08-03 00:00:52.041209' LIMIT 1;
REPLACE INTO `t500_tokudb_default_int` (`c7`) VALUES (1);
===============
After several hours of hacking reducer.sh to use SOURCE (thanks Ramesh!) and reducer- script- handholding, we finally have a good/short testcase for this bug!
=============== tokudb_ small` ( tokudb_ small; tokudb_ small` FOR EXPORT; compressed` SET `c9`='2001-08-03 00:00:52.041209' LIMIT 1; default_ int` (`c7`) VALUES (1);
DROP DATABASE transforms;CREATE DATABASE transforms;DROP DATABASE test;CREATE DATABASE test;USE test;
CREATE TABLE `t100_innodb_
`c17` text CHARACTER SET latin1,
key (`c17` (1))) ENGINE=innodb ROW_FORMAT=
SET AUTOCOMMIT=OFF;
FLUSH TABLES `t100_innodb_
LOCK BINLOG FOR BACKUP;
UNLOCK TABLES;
UNLOCK BINLOG;
UPDATE LOW_PRIORITY `t100_innodb_
REPLACE INTO `t500_tokudb_
===============
Server startup command example:
/sda/Percona- Server- 5.6.21- rel70.0- 693.Linux. x86_64/ bin/mysqld --no-defaults --basedir= /sda/Percona- Server- 5.6.21- rel70.0- 693.Linux. x86_64 --datadir= /dev/shm/ 1417519395/ data --tmpdir= /dev/shm/ 1417519395/ tmp --port=37921 --pid-file= /dev/shm/ 1417519395/ pid.pid --socket= /dev/shm/ 1417519395/ socket. sock --user=roel --log-output=none --sql_mode= ONLY_FULL_ GROUP_BY --log-error= /dev/shm/ 1417519395/ error.log. out --event- scheduler= ON
* If you SOURCE it in optimized build, you get a hang (to be confirmed outside reducer. works fine in my hacked reducer)
* If you paste it into an optimized CLI, you get a sig11
/sda/ Percona- Server- 5.6.21- rel70.0- 693.Linux. x86_64/ bin/mysqld( _ZN11MDL_ context12releas e_lockE17enum_ mdl_durationP10 MDL_ticket+ 0x32)[0x66a422] Percona- Server- 5.6.21- rel70.0- 693.Linux. x86_64/ bin/mysqld( _ZN11MDL_ context27releas e_locks_ stored_ beforeE17enum_ mdl_durationP10 MDL_ticket+ 0x35)[0x66a485] Percona- Server- 5.6.21- rel70.0- 693.Linux. x86_64/ bin/mysqld( _ZN11MDL_ context21rollba ck_to_savepoint ERK13MDL_ savepoint+ 0x17)[0x66a6f7]
/sda/
/sda/
* If you paste it into a debug CLI, you get an assert (https:/ /bugs.launchpad .net/percona- server/ +bug/1377093)
mysqld: /mnt/workspace/ percona- server- 5.6-binaries- debug-yassl/ label_exp/ centos6- 64/percona- server- 5.6.21- 69.0/sql/ lock.cc: 1142: void Global_ backup_ lock::release( THD*): Assertion `m_lock != __null && thd->mdl_ context. is_lock_ owner(m_ namespace, "", "", MDL_SHARED)' failed.
* If you source it in debug, you get another crash (No existing bug report yet it looks like)
/sda/ Percona- Server- 5.6.21- rel69.0- 687.Linux. x86_64- debug/bin/ mysqld( _ZN18Global_ backup_ lock7releaseEP3 THD+0x8e) [0x957aa8] Percona- Server- 5.6.21- rel69.0- 687.Linux. x86_64- debug/bin/ mysqld( _Z21mysql_ execute_ commandP3THD+ 0x4399) [0x7e66c8] Percona- Server- 5.6.21- rel69.0- 687.Linux. x86_64- debug/bin/ mysqld( _Z11mysql_ parseP3THDPcjP1 2Parser_ state+0x5a6) [0x7ed4bf]
/sda/
/sda/
* There are other related crashes. May reduce those seperately tomorrow.
As said, this looks serious.