Description:
When a temporary table is updated to switch the storage engine after issuing a LOCK TABLES statement, it seems like the internal InnoDB transaction's variable, "in_depth" which keeps track of the nested level of statements is not handled properly during the client disconnection section and causes the following debug assertion to hit and the server crashes.
2024-06-24T10:38:15.509625Z 9 [ERROR] [MY-013183] [InnoDB] Assertion failure: trx0trx.cc:507:trx->in_depth == 0 thread 132540212889152
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/refman/8.0/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
2024-06-24T10:38:15Z UTC - mysqld got signal 6 ;
This issue was uncovered by a recent patch in MySQL 8.0.37
Bug#35277407 InnoDB：trx hangs due to wrong trx->in_innodb value | https://github.com/mysql/mysql-server/commit/88b0ebafdf6
How to repeat:
Run the following testcase and the server crashes at the shutdown statement. The shutdown statement can be replaced with just a client exit and the server still crashes.
source include/have_debug.inc;
CREATE TABLE tab(col INT, PRIMARY KEY(col)) ENGINE=MyISAM;
LOCK TABLES tab WRITE;
CREATE TEMPORARY TABLE t1(col INT, INDEX(col)) ENGINE=InnoDB;
ALTER TABLE t1 ENGINE=MyISAM;
DROP TABLE t1;
UNLOCK TABLES;
source include/shutdown_mysqld.inc;
source include/start_mysqld.inc;
DROP TABLE tab;
