[MDEV-23365] Assertion `!is_set() || (m_status == DA_OK_BULK && is_bulk_op())' failed upon killed TRUNCATE Created: 2020-08-01  Updated: 2021-09-07  Resolved: 2021-09-07

Status: Closed
Project: MariaDB Server
Component/s: Server
Affects Version/s: 10.1, 10.2
Fix Version/s: 10.2.41

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


 Description   

Setting to minor because it seems to only affect 10.2.

It may be related to all or any or none of numerous diagnostics area issues, I don't have enough information to link them.

The first test case is more "natural" (uses the real KILL), and it fails very well for me, but still, it's not deterministic, run with --repeat if it doesn't fail right away. The alternative second test case uses the odd behavior of max_session_mem_used. The effect usually depends on the type of the build, either it causes the query look like it was killed (which this test case exploits to avoid the race condition), or it fails with a proper error message, then there will be no assertion failure.

test case 1

CREATE TABLE t1 (a INT) ENGINE=MyISAM;
LOCK TABLE t1 READ;
 
--connect (con1,localhost,root,,test)
--let $conid= `select connection_id()`
--send
  LOCK TABLE t1 WRITE;
 
--connection default
SELECT * FROM t1;
UNLOCK TABLES;
 
--connection con1
--reap
--send
  TRUNCATE TABLE t1;
 
--connection default
--eval KILL QUERY $conid
 
--connection con1
--error 0,ER_QUERY_INTERRUPTED
--reap
DROP TABLE t1;

Test case 2

CREATE TABLE t1 (a INT) ENGINE=MyISAM;
LOCK TABLE t1 READ;
 
--connect (con1,localhost,root,,test)
SET SESSION max_session_mem_used= 65536;
--send
  LOCK TABLE t1 WRITE;
 
--connection default
SELECT * FROM t1;
UNLOCK TABLES;
 
--connection con1
--reap
--error ER_OPTION_PREVENTS_STATEMENT
TRUNCATE TABLE t1;
 
DROP TABLE t1;

10.2 5ec40fbb

mysqld: /data/src/10.2/sql/sql_error.cc:380: void Diagnostics_area::set_ok_status(ulonglong, ulonglong, const char*): Assertion `!is_set() || (m_status == DA_OK_BULK && is_bulk_op())' failed.
200802  1:18:08 [ERROR] mysqld got signal 6 ;
 
Query (0x7f5970011098): TRUNCATE TABLE t1
Connection ID (thread ID): 5
Status: KILL_QUERY

#7  0x00007f5992827f12 in __GI___assert_fail (assertion=0x559d0c453438 "!is_set() || (m_status == DA_OK_BULK && is_bulk_op())", file=0x559d0c453370 "/data/src/10.2/sql/sql_error.cc", line=380, function=0x559d0c453780 <Diagnostics_area::set_ok_status(unsigned long long, unsigned long long, char const*)::__PRETTY_FUNCTION__> "void Diagnostics_area::set_ok_status(ulonglong, ulonglong, const char*)") at assert.c:101
#8  0x0000559d0b9a82b3 in Diagnostics_area::set_ok_status (this=0x7f5970005ca0, affected_rows=0, last_insert_id=0, message=0x0) at /data/src/10.2/sql/sql_error.cc:380
#9  0x0000559d0b95b577 in my_ok (thd=0x7f5970000af0, affected_rows=0, id=0, message=0x0) at /data/src/10.2/sql/sql_class.h:4560
#10 0x0000559d0be0d673 in Sql_cmd_truncate_table::execute (this=0x7f5970011788, thd=0x7f5970000af0) at /data/src/10.2/sql/sql_truncate.cc:498
#11 0x0000559d0b9dd218 in mysql_execute_command (thd=0x7f5970000af0) at /data/src/10.2/sql/sql_parse.cc:5964
#12 0x0000559d0b9e2199 in mysql_parse (thd=0x7f5970000af0, rawbuf=0x7f5970011098 "TRUNCATE TABLE t1", length=17, parser_state=0x7f598cb10610, is_com_multi=false, is_next_command=false) at /data/src/10.2/sql/sql_parse.cc:7733
#13 0x0000559d0b9d04c5 in dispatch_command (command=COM_QUERY, thd=0x7f5970000af0, packet=0x7f59700088b1 "TRUNCATE TABLE t1", packet_length=17, is_com_multi=false, is_next_command=false) at /data/src/10.2/sql/sql_parse.cc:1824
#14 0x0000559d0b9cef40 in do_command (thd=0x7f5970000af0) at /data/src/10.2/sql/sql_parse.cc:1377
#15 0x0000559d0bb2502d in do_handle_one_connection (connect=0x559d0e823010) at /data/src/10.2/sql/sql_connect.cc:1336
#16 0x0000559d0bb24d98 in handle_one_connection (arg=0x559d0e823010) at /data/src/10.2/sql/sql_connect.cc:1241
#17 0x0000559d0c33b730 in pfs_spawn_thread (arg=0x559d0e8bed50) at /data/src/10.2/storage/perfschema/pfs.cc:1869
#18 0x00007f59947b04a4 in start_thread (arg=0x7f598cb11700) at pthread_create.c:456
#19 0x00007f59928e4d0f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:97

Couldn't reproduce on 10.3+.



 Comments   
Comment by Rucha Deodhar [ 2020-12-15 ]

Patch: https://github.com/MariaDB/server/commit/3b62843a6e0f2eddcb92bf980eda1990145a8cb7

Comment by Sergei Golubchik [ 2021-07-24 ]

10.3 doesn't have this bug. Because it, apparently, have it fixed already.

Please backport the fix from 10.3 to have the same solution everywhere (and less merge conflicts too).

Comment by Rucha Deodhar [ 2021-07-27 ]

Backported, patch: https://github.com/MariaDB/server/commit/c937067f7e239f72beb8de17b5bfe42b9bd04c49

Comment by Sergei Golubchik [ 2021-07-27 ]

ok to push, thanks.

you could've mentioned in the commit comment something like

this is a 10.2 backport of 1cb4caa66d5fd2a9bc095d68988324b7b358d70f

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