[MDEV-17749] Kill during LOCK TABLE ; ALTER TABLE causes assert - Jira

Details

Type: Bug
Status: Closed (View Workflow)
Priority: Critical
Resolution: Fixed
Affects Version/s: 10.1(EOL), 10.2(EOL), 10.3(EOL), 10.4(EOL), 10.5
Fix Version/s: 10.6.2, 10.3.30, 10.4.20, 10.5.11
Component/s: Data Definition - Alter Table, Locking
Labels:
- affects-tests

Description

--source include/have_innodb.inc

CREATE TABLE t1 (a INT) ENGINE=InnoDB;

--connect (con1,localhost,root,,test)

LOCK TABLE t1 WRITE;

--let $conid= `SELECT CONNECTION_ID()`

--send

  ALTER TABLE t1 ADD COLUMN b INT;

--connection default

eval KILL $conid;

# Cleanup

DROP TABLE t1;

10.4 2d4b6571
mysqld: /data/src/10.4/sql/sql_base.cc:2455: void Locked_tables_list::unlock_locked_tables(THD*): Assertion `thd->transaction.stmt.is_empty()' failed.
200114 13:50:15 [ERROR] mysqld got signal 6 ;

#7 0x00007ff8cad17f12 in __GI___assert_fail (assertion=0x55779cd65850 "thd->transaction.stmt.is_empty()", file=0x55779cd64fd0 "/data/src/10.4/sql/sql_base.cc", line=2455, function=0x55779cd67280 <Locked_tables_list::unlock_locked_tables(THD)::__PRETTY_FUNCTION__> "void Locked_tables_list::unlock_locked_tables(THD)") at assert.c:101
#8 0x000055779bfdb370 in Locked_tables_list::unlock_locked_tables (this=0x7ff870004860, thd=0x7ff870000af0) at /data/src/10.4/sql/sql_base.cc:2455
#9 0x000055779bfdb7b3 in Locked_tables_list::unlink_all_closed_tables (this=0x7ff870004860, thd=0x7ff870000af0, lock=0x0, reopen_count=0) at /data/src/10.4/sql/sql_base.cc:2634
#10 0x000055779bfdba52 in Locked_tables_list::reopen_tables (this=0x7ff870004860, thd=0x7ff870000af0, need_reopen=false) at /data/src/10.4/sql/sql_base.cc:2688
#11 0x000055779c172e9e in mysql_alter_table (thd=0x7ff870000af0, new_db=0x7ff8700052b0, new_name=0x7ff8700056b8, create_info=0x7ff8c409bcf0, table_list=0x7ff870011ec0, alter_info=0x7ff8c409bc30, order_num=0, order=0x0, ignore=false) at /data/src/10.4/sql/sql_table.cc:10397
#12 0x000055779c20a341 in Sql_cmd_alter_table::execute (this=0x7ff8700126a8, thd=0x7ff870000af0) at /data/src/10.4/sql/sql_alter.cc:508
#13 0x000055779c088d95 in mysql_execute_command (thd=0x7ff870000af0) at /data/src/10.4/sql/sql_parse.cc:6102
#14 0x000055779c08e457 in mysql_parse (thd=0x7ff870000af0, rawbuf=0x7ff870011dd8 "ALTER TABLE t1 ADD COLUMN b INT", length=31, parser_state=0x7ff8c409d160, is_com_multi=false, is_next_command=false) at /data/src/10.4/sql/sql_parse.cc:7901
#15 0x000055779c0795fc in dispatch_command (command=COM_QUERY, thd=0x7ff870000af0, packet=0x7ff8700083a1 "ALTER TABLE t1 ADD COLUMN b INT", packet_length=31, is_com_multi=false, is_next_command=false) at /data/src/10.4/sql/sql_parse.cc:1842
#16 0x000055779c077c89 in do_command (thd=0x7ff870000af0) at /data/src/10.4/sql/sql_parse.cc:1360
#17 0x000055779c200c51 in do_handle_one_connection (connect=0x5577a04668e0) at /data/src/10.4/sql/sql_connect.cc:1412
#18 0x000055779c2009a0 in handle_one_connection (arg=0x5577a04668e0) at /data/src/10.4/sql/sql_connect.cc:1316
#19 0x000055779cc06b0d in pfs_spawn_thread (arg=0x5577a03d3360) at /data/src/10.4/storage/perfschema/pfs.cc:1862
#20 0x00007ff8ccca04a4 in start_thread (arg=0x7ff8c409e700) at pthread_create.c:456
#21 0x00007ff8cadd4d0f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:97

Reproducible with 10.1-10.5.
The test case fails for me every time, but it still involves a race condition, so try to run with --repeat=N if it doesn't fail right away.
No obvious problem on a non-debug build.

Attachments

Issue Links

is caused by

MDEV-5587 Server crashes in Locked_tables_list::restore_lock on CREATE OR REPLACE .. SELECT under LOCK

Closed

Activity

Ascending order - Click to sort in descending order

View 11 older comments

Sergei Golubchik added a comment - 2020-10-23 08:04

note to self: the commit c2b3a4c253a76c1aaa6ef5d96bb7995afc3a572b maikes rocksdb.kill to fail

Sergei Golubchik added a comment - 2020-10-23 08:04 note to self: the commit c2b3a4c253a76c1aaa6ef5d96bb7995afc3a572b maikes rocksdb.kill to fail

Sergei Golubchik added a comment - 2020-10-26 19:41

it seems like we generally do unlock automatically when there are no more locked tables.

Sergei Golubchik added a comment - 2020-10-26 19:41 it seems like we generally do unlock automatically when there are no more locked tables.

Roel Van de Paar added a comment - 2020-10-27 09:39 - edited

10.6 dbg stack looks similar, however there is something interesting on 10.6 opt builds:

10.6.0 5d4599f9750140f92cfdbbe4d292ae1b8dd456f8 (Optimized)
10.6.0>CREATE TABLE t1 (a INT) ENGINE=InnoDB;
Query OK, 0 rows affected (0.010 sec)
10.6.0>SELECT * FROM t1;
Empty set (0.001 sec)
10.6.0>SET SESSION MAX_SESSION_MEM_USED= @@max_session_mem_used + 1024;
Query OK, 0 rows affected (0.000 sec)
10.6.0>LOCK TABLES t1 WRITE;
Query OK, 0 rows affected (0.000 sec)
10.6.0>ALTER TABLE t1 FORCE;
ERROR 1317 (70100): Query execution was interrupted

Consistently reproducible. Re-opening the CLI and re-executing the same gives:

10.6.0>ALTER TABLE t1 FORCE;

Query OK, 0 rows affected (0.017 sec)

Records: 0  Duplicates: 0  Warnings: 0

10.6.0>ALTER TABLE t1 FORCE;

Query OK, 0 rows affected (0.019 sec)

Records: 0  Duplicates: 0  Warnings: 0

Roel Van de Paar added a comment - 2020-10-27 09:39 - edited 10.6 dbg stack looks similar, however there is something interesting on 10.6 opt builds: 10.6.0 5d4599f9750140f92cfdbbe4d292ae1b8dd456f8 (Optimized) 10.6.0>CREATE TABLE t1 (a INT) ENGINE=InnoDB; Query OK, 0 rows affected (0.010 sec) 10.6.0>SELECT * FROM t1; Empty set (0.001 sec) 10.6.0>SET SESSION MAX_SESSION_MEM_USED= @@max_session_mem_used + 1024; Query OK, 0 rows affected (0.000 sec) 10.6.0>LOCK TABLES t1 WRITE; Query OK, 0 rows affected (0.000 sec) 10.6.0>ALTER TABLE t1 FORCE; ERROR 1317 (70100): Query execution was interrupted Consistently reproducible. Re-opening the CLI and re-executing the same gives: 10.6.0>ALTER TABLE t1 FORCE; Query OK, 0 rows affected (0.017 sec) Records: 0 Duplicates: 0 Warnings: 0 10.6.0>ALTER TABLE t1 FORCE; Query OK, 0 rows affected (0.019 sec) Records: 0 Duplicates: 0 Warnings: 0

Michael Widenius added a comment - 2021-05-26 11:28

The same bug also affects LOCK TABLES ; CREATE TRIGGER:

CREATE TABLE t1 (id int(11)) ENGINE=InnoDB;
LOCK TABLES t1 WRITE;
SET max_statement_time= 0.0001;
--error 0,1969
--disable_warnings
CREATE TRIGGER tr16 AFTER UPDATE ON t1 FOR EACH ROW INSERT INTO t1 VALUES (1);
--enable_warnings
SET max_statement_time= default;
DROP TRIGGER IF EXISTS trg16;
DROP TABLE t1;

Michael Widenius added a comment - 2021-05-26 11:28 The same bug also affects LOCK TABLES ; CREATE TRIGGER: CREATE TABLE t1 (id int(11)) ENGINE=InnoDB; LOCK TABLES t1 WRITE; SET max_statement_time= 0.0001; --error 0,1969 --disable_warnings CREATE TRIGGER tr16 AFTER UPDATE ON t1 FOR EACH ROW INSERT INTO t1 VALUES (1); --enable_warnings SET max_statement_time= default; DROP TRIGGER IF EXISTS trg16; DROP TABLE t1;

Michael Widenius added a comment - 2021-05-26 12:36

Fixed

The problem was that when LOCK TABLES where unwinded as part of
a killed connection, unlink_all_closed_tables() did not like that
there was uncommitted transactions.
Fixed by doing a rollback of any open transaction in this particular case.

Michael Widenius added a comment - 2021-05-26 12:36 Fixed The problem was that when LOCK TABLES where unwinded as part of a killed connection, unlink_all_closed_tables() did not like that there was uncommitted transactions. Fixed by doing a rollback of any open transaction in this particular case.

MariaDB Server

Kill during LOCK TABLE ; ALTER TABLE causes assert

Details

Description

Attachments

Issue Links

Activity

People

Dates

Git Integration