[MDEV-15769] Assertion `!is_set() || (m_status == DA_OK_BULK && is_bulk_op())' failed in Diagnostics_area::set_ok_status (again) Created: 2018-04-03  Updated: 2018-04-07  Resolved: 2018-04-07

Status: Closed
Project: MariaDB Server
Component/s: Locking
Affects Version/s: 10.2
Fix Version/s: 10.2.15

Type: Bug Priority: Critical
Reporter: Elena Stepanova Assignee: Sergei Petrunia
Resolution: Fixed Votes: 0
Labels: None


 Description   

CREATE TABLE t1 (a INT);
CREATE TABLE t2 (b INT);
LOCK TABLE t1 READ;
 
--connect (con1,localhost,root,,test)
LOCK TABLE t2 WRITE;
SET lock_wait_timeout= 1;
FLUSH TABLES;
 
# Cleanup
UNLOCK TABLES;
--disconnect con1
--connection default
UNLOCK TABLES;
DROP TABLE t1, t2;

10.2 55f4e4800bc5

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.
180404  2:04:18 [ERROR] mysqld got signal 6 ;
 
#7  0x00007fc837a80ee2 in __assert_fail () from /lib/x86_64-linux-gnu/libc.so.6
#8  0x0000563d93c78e5b in Diagnostics_area::set_ok_status (this=0x7fc814005c90, affected_rows=0, last_insert_id=0, message=0x0) at /data/src/10.2/sql/sql_error.cc:380
#9  0x0000563d93c2b4b7 in my_ok (thd=0x7fc814000b00, affected_rows=0, id=0, message=0x0) at /data/src/10.2/sql/sql_class.h:4492
#10 0x0000563d93cabdf6 in mysql_execute_command (thd=0x7fc814000b00) at /data/src/10.2/sql/sql_parse.cc:5439
#11 0x0000563d93cb324e in mysql_parse (thd=0x7fc814000b00, rawbuf=0x7fc814011138 "FLUSH TABLES", length=12, parser_state=0x7fc831d12200, is_com_multi=false, is_next_command=false) at /data/src/10.2/sql/sql_parse.cc:7914
#12 0x0000563d93ca1109 in dispatch_command (command=COM_QUERY, thd=0x7fc814000b00, packet=0x7fc814008951 "FLUSH TABLES", packet_length=12, is_com_multi=false, is_next_command=false) at /data/src/10.2/sql/sql_parse.cc:1815
#13 0x0000563d93c9fa6c in do_command (thd=0x7fc814000b00) at /data/src/10.2/sql/sql_parse.cc:1369
#14 0x0000563d93dee326 in do_handle_one_connection (connect=0x563d96c75d60) at /data/src/10.2/sql/sql_connect.cc:1335
#15 0x0000563d93dee0b3 in handle_one_connection (arg=0x563d96c75d60) at /data/src/10.2/sql/sql_connect.cc:1241
#16 0x0000563d9420e284 in pfs_spawn_thread (arg=0x563d96bc0280) at /data/src/10.2/storage/perfschema/pfs.cc:1862
#17 0x00007fc839757494 in start_thread (arg=0x7fc831d13700) at pthread_create.c:333
#18 0x00007fc837b3d93f in clone () from /lib/x86_64-linux-gnu/libc.so.6

The failure appeared in 10.2 with this commit:

commit b922741074bd2bf2b56b0381d1f32af0a3df4063
Author: Sergei Petrunia <psergey@askmonty.org>
Date:   Thu Mar 29 13:59:21 2018 +0300
 
    MDEV-15472: Assertion `!is_set() || (m_status == DA_OK_BULK && is_bulk_op())' failure
    
    MariaDB differs from the upstream for "DDL-like" command. For these,
    it sets binlog_format=STATEMENT for the duration of the statement.
    This doesn't play well with MyRocks, which tries to prevent DML
    commands with binlog_format!=ROW.
    
    Also, if Locked_tables_list::reopen_tables() returned an error, then
    close_cached_tables should propagate the error condition and not silently
    consume it (it's difficult to have test coverage for this because this
    error condition is rare)



 Comments   
Comment by Sergei Petrunia [ 2018-04-07 ]

Confirm. This change in the patch causes the testcase for this bug to start crashing:

diff --git a/sql/sql_base.cc b/sql/sql_base.cc
index ca3141b..53f741b 100644
--- a/sql/sql_base.cc
+++ b/sql/sql_base.cc
@@ -481,7 +481,7 @@ bool close_cached_tables(THD *thd, TABLE_LIST *tables,
       old locks. This should always succeed (unless some external process
       has removed the tables)
     */
-    result= thd->locked_tables_list.reopen_tables(thd);
+    thd->locked_tables_list.reopen_tables(thd);
     /*
       Since downgrade_lock() won't do anything with shared
       metadata lock it is much simpler to go through all open tables rather

Comment by Sergei Petrunia [ 2018-04-07 ]

Ok, the issue happens when we get here and result=1. if reopen_tables() returns 0, we should still return 1 from this function.

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