Details
-
Bug
-
Status: Closed (View Workflow)
-
Minor
-
Resolution: Fixed
-
10.1(EOL), 10.2(EOL)
-
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+.
Attachments
Activity
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).
Backported, patch: https://github.com/MariaDB/server/commit/c937067f7e239f72beb8de17b5bfe42b9bd04c49
ok to push, thanks.
you could've mentioned in the commit comment something like
this is a 10.2 backport of 1cb4caa66d5fd2a9bc095d68988324b7b358d70f
Patch: https://github.com/MariaDB/server/commit/3b62843a6e0f2eddcb92bf980eda1990145a8cb7