[MDEV-23836] Assertion `! is_set() || m_can_overwrite_status' in Diagnostics_area::set_error_status (interrupted ALTER TABLE under LOCK) Created: 2020-09-28  Updated: 2022-01-10  Resolved: 2022-01-10

Status: Closed
Project: MariaDB Server
Component/s: Data Definition - Alter Table, Locking
Affects Version/s: 10.5
Fix Version/s: 10.5.14, 10.6.6

Type: Bug Priority: Major
Reporter: Elena Stepanova Assignee: Rucha Deodhar
Resolution: Fixed Votes: 0
Labels: None

Issue Links:
Relates
relates to MDEV-21398 Deadlock (server hang) or assertion f... Closed

 Description   

The failure described below disappeared from 10.2-10.4 branches a while ago after this commit:

commit be647ff14d6196af825f05020acee8f18af4773d
Author: Monty
Date:   Fri May 22 18:02:24 2020 +0300
 
    Fixed deadlock with LOCK TABLES and ALTER TABLE
    
    MDEV-21398 Deadlock (server hang) or assertion failure in
    Diagnostics_area::set_error_status upon ALTER under lock

However, it didn't have the same effect on 10.5. The original test case provided in MDEV-21398 was fixed by the patch in all versions, including 10.5, but the one described here still fails on 10.5.

There are two variations of the test case. Test 1 is non-deterministic, as it involves concurrency, even though it fails every time for me. Test 2 appears to be deterministic (it might depend on the build), but it involves the use of max_session_mem_used which essentially allows to imitate killing a query without any concurrency involved.

Please feel free to choose whichever is easier to debug. At the end, the result is the same.

Test 1

CREATE TABLE t1 (a INT);
SELECT * FROM t1;
 
--connect (con1,localhost,root,,)
 
--error ER_NO_SUCH_TABLE
ALTER TABLE x MODIFY xx INT;
 
LOCK TABLE t1 WRITE;
--let $conid = `select connection_id()`
--send
  ALTER TABLE t1 CHANGE COLUMN IF EXISTS b c INT;
 
--connection default
eval KILL QUERY $conid;
 
# Cleanup
--disconnect con1
DROP TABLE t1;

Test 2

CREATE TABLE t1 (a INT);
SELECT * FROM t1;
 
--error ER_NO_SUCH_TABLE
ALTER TABLE x MODIFY xx INT;
 
SET SESSION max_session_mem_used= 8192;
LOCK TABLE t1 WRITE;
ALTER TABLE t1 CHANGE COLUMN IF EXISTS b c INT;
 
DROP TABLE t1;

10.5 6ab6b151

mariadbd: /data/src/10.5/sql/sql_error.cc:445: void Diagnostics_area::set_error_status(uint, const char*, const char*, const Sql_user_condition_identity&, const Sql_condition*): Assertion `! is_set() || m_can_overwrite_status' failed.
200929  0:18:57 [ERROR] mysqld got signal 6 ;
 
#7  0x00007ff49fe71f36 in __GI___assert_fail (assertion=0x55eee5195fe8 "! is_set() || m_can_overwrite_status", file=0x55eee5195d80 "/data/src/10.5/sql/sql_error.cc", line=445, function=0x55eee5196010 "void Diagnostics_area::set_error_status(uint, const char*, const char*, const Sql_user_condition_identity&, const Sql_condition*)") at assert.c:101
#8  0x000055eee42b6fee in Diagnostics_area::set_error_status (this=0x7ff47c006a40, sql_errno=1317, message=0x55eee534dc10 "Query execution was interrupted", sqlstate=0x55eee51bfb6b "70100", ucid=..., error_condition=0x0) at /data/src/10.5/sql/sql_error.cc:445
#9  0x000055eee42902e5 in THD::raise_condition (this=0x7ff47c000db8, sql_errno=1317, sqlstate=0x55eee51bfb6b "70100", level=Sql_state_errno_level::WARN_LEVEL_ERROR, ucid=..., msg=0x55eee534dc10 "Query execution was interrupted") at /data/src/10.5/sql/sql_class.cc:1142
#10 0x000055eee41cd31c in THD::raise_condition (this=0x7ff47c000db8, sql_errno=1317, sqlstate=0x0, level=Sql_state_errno_level::WARN_LEVEL_ERROR, msg=0x55eee534dc10 "Query execution was interrupted") at /data/src/10.5/sql/sql_class.h:4533
#11 0x000055eee41c00e3 in my_message_sql (error=1317, str=0x55eee534dc10 "Query execution was interrupted", MyFlags=0) at /data/src/10.5/sql/mysqld.cc:3113
#12 0x000055eee4fc036e in my_message (error=1317, str=0x55eee534dc10 "Query execution was interrupted", MyFlags=0) at /data/src/10.5/mysys/my_error.c:196
#13 0x000055eee421e033 in THD::send_kill_message (this=0x7ff47c000db8) at /data/src/10.5/sql/sql_class.h:4203
#14 0x000055eee4263112 in open_table (thd=0x7ff47c000db8, table_list=0x7ff47c01a990, ot_ctx=0x7ff499f07cd0) at /data/src/10.5/sql/sql_base.cc:1685
#15 0x000055eee426574d in Locked_tables_list::reopen_tables (this=0x7ff47c004d88, thd=0x7ff47c000db8, need_reopen=true) at /data/src/10.5/sql/sql_base.cc:2635
#16 0x000055eee4318fbf in mysql_execute_command (thd=0x7ff47c000db8) at /data/src/10.5/sql/sql_parse.cc:5986
#17 0x000055eee431eeba in mysql_parse (thd=0x7ff47c000db8, rawbuf=0x7ff47c012ac0 "ALTER TABLE t1 CHANGE COLUMN IF EXISTS b c INT", length=46, parser_state=0x7ff499f08510, is_com_multi=false, is_next_command=false) at /data/src/10.5/sql/sql_parse.cc:7994
#18 0x000055eee430b1f8 in dispatch_command (command=COM_QUERY, thd=0x7ff47c000db8, packet=0x7ff47c009099 "ALTER TABLE t1 CHANGE COLUMN IF EXISTS b c INT", packet_length=46, is_com_multi=false, is_next_command=false) at /data/src/10.5/sql/sql_parse.cc:1867
#19 0x000055eee43099ec in do_command (thd=0x7ff47c000db8) at /data/src/10.5/sql/sql_parse.cc:1348
#20 0x000055eee44b577c in do_handle_one_connection (connect=0x55eee6cb1668, put_in_cache=true) at /data/src/10.5/sql/sql_connect.cc:1410
#21 0x000055eee44b54e4 in handle_one_connection (arg=0x55eee6cb1668) at /data/src/10.5/sql/sql_connect.cc:1312
#22 0x000055eee4a119af in pfs_spawn_thread (arg=0x55eee6cb1748) at /data/src/10.5/storage/perfschema/pfs.cc:2201
#23 0x00007ff4a0389609 in start_thread (arg=<optimized out>) at pthread_create.c:477
#24 0x00007ff49ff5d293 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
 
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
Query (0x7f916c013f20): ALTER TABLE t1 CHANGE COLUMN IF EXISTS b c INT
 
Connection ID (thread ID): 4
Status: KILL_QUERY

Reproducible with at least MyISAM and InnoDB.
No obvious immediate problem on a non-debug build.



 Comments   
Comment by Rucha Deodhar [ 2020-10-20 ]

Patch:
https://github.com/MariaDB/server/commit/31dbfb5e617b19ffea6ea6350207e48cdcd371d7

Comment by Sergei Golubchik [ 2022-01-09 ]

31dbfb5e617b19ffea6ea6350207e48cdcd371d7 is ok to push

Generated at Thu Feb 08 09:25:25 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.