[MDEV-10435] crash with bad stat tables Created: 2016-07-25  Updated: 2016-12-09  Resolved: 2016-12-09

Status: Closed
Project: MariaDB Server
Component/s: OTHER
Affects Version/s: 10.1
Fix Version/s: 10.1.20

Type: Bug Priority: Critical
Reporter: Sergei Golubchik Assignee: Alexey Botchkov
Resolution: Fixed Votes: 0
Labels: None

Sprint: 10.2.4-1

 Description   

rename table mysql.table_stats to test.table_stats;
flush tables;
create table t1 (a int);
rename table t1 to t2, t3 to t4;
drop table t1;
rename table test.table_stats to mysql.table_stats;

rename table mysql.table_stats to test.table_stats;
create table mysql.table_stats (a int);
flush tables;
create table t1 (a int);
rename table t1 to t2, t3 to t4;
drop table t1, mysql.table_stats;
rename table test.table_stats to mysql.table_stats;

First test case, debug server

mysqld: /data/src/10.1/sql/protocol.cc:523: void Protocol::end_statement(): Assertion `0' failed.
160725 21:30:51 [ERROR] mysqld got signal 6 ;
 
#6  0x00007f33f1eba266 in __assert_fail_base (fmt=0x7f33f1ff3238 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=assertion@entry=0x7f33f4fb7df0 "0", file=file@entry=0x7f33f4fb7e70 "/data/src/10.1/sql/protocol.cc", line=line@entry=523, function=function@entry=0x7f33f4fb8860 <Protocol::end_statement()::__PRETTY_FUNCTION__> "void Protocol::end_statement()") at assert.c:92
#7  0x00007f33f1eba312 in __GI___assert_fail (assertion=0x7f33f4fb7df0 "0", file=0x7f33f4fb7e70 "/data/src/10.1/sql/protocol.cc", line=523, function=0x7f33f4fb8860 <Protocol::end_statement()::__PRETTY_FUNCTION__> "void Protocol::end_statement()") at assert.c:101
#8  0x00007f33f46088ce in Protocol::end_statement (this=0x7f33ce356600) at /data/src/10.1/sql/protocol.cc:523
#9  0x00007f33f46bdab4 in dispatch_command (command=COM_QUERY, thd=0x7f33ce356070, packet=0x7f33ce2bb071 "rename table t1 to t2, t3 to t4", packet_length=31) at /data/src/10.1/sql/sql_parse.cc:1939
#10 0x00007f33f46bb21b in do_command (thd=0x7f33ce356070) at /data/src/10.1/sql/sql_parse.cc:1107
#11 0x00007f33f47f0e45 in do_handle_one_connection (thd_arg=0x7f33ce356070) at /data/src/10.1/sql/sql_connect.cc:1350
#12 0x00007f33f47f0ba9 in handle_one_connection (arg=0x7f33ce356070) at /data/src/10.1/sql/sql_connect.cc:1262
#13 0x00007f33f3dbc0a4 in start_thread (arg=0x7f33f55f2b00) at pthread_create.c:309
#14 0x00007f33f1f7487d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111

Second test case, debug server

#3  <signal handler called>
#4  0x00007fd9a9703b5a in Stat_table::common_init_stat_table (this=0x7fd9aa589240) at /data/src/10.1/sql/sql_statistics.cc:318
#5  0x00007fd9a9703d76 in Stat_table::Stat_table (this=0x7fd9aa589240, stat=0x7fd9a6758c70, db=0x7fd9aa58a930, tab=0x7fd9aa58a940) at /data/src/10.1/sql/sql_statistics.cc:391
#6  0x00007fd9a9704292 in Table_stat::Table_stat (this=0x7fd9aa589240, stat=0x7fd9a6758c70, db=0x7fd9aa58a930, tab=0x7fd9aa58a940) at /data/src/10.1/sql/sql_statistics.cc:656
#7  0x00007fd9a97020eb in rename_table_in_stat_tables (thd=0x7fd983356070, db=0x7fd9aa58a930, tab=0x7fd9aa58a940, new_db=0x7fd9aa58a960, new_tab=0x7fd9aa58a950) at /data/src/10.1/sql/sql_statistics.cc:3441
#8  0x00007fd9a9684425 in do_rename (thd=0x7fd983356070, ren_table=0x7fd97a0221a0, new_db=0x7fd97a022d90 "test", new_table_name=0x7fd97a022168 "t2", new_table_alias=0x7fd97a022798 "t2", skip_error=false) at /data/src/10.1/sql/sql_rename.cc:279
#9  0x00007fd9a968462c in rename_tables (thd=0x7fd983356070, table_list=0x7fd97a0221a0, skip_error=false) at /data/src/10.1/sql/sql_rename.cc:354
#10 0x00007fd9a9683fcc in mysql_rename_tables (thd=0x7fd983356070, table_list=0x7fd97a0221a0, silent=false) at /data/src/10.1/sql/sql_rename.cc:153
#11 0x00007fd9a965bf2f in mysql_execute_command (thd=0x7fd983356070) at /data/src/10.1/sql/sql_parse.cc:3613
#12 0x00007fd9a9667aba in mysql_parse (thd=0x7fd983356070, rawbuf=0x7fd97a022088 "rename table t1 to t2, t3 to t4", length=31, parser_state=0x7fd9aa58b630) at /data/src/10.1/sql/sql_parse.cc:7314
#13 0x00007fd9a96564e4 in dispatch_command (command=COM_QUERY, thd=0x7fd983356070, packet=0x7fd9832bb071 "rename table t1 to t2, t3 to t4", packet_length=31) at /data/src/10.1/sql/sql_parse.cc:1486
#14 0x00007fd9a965521b in do_command (thd=0x7fd983356070) at /data/src/10.1/sql/sql_parse.cc:1107
#15 0x00007fd9a978ae45 in do_handle_one_connection (thd_arg=0x7fd983356070) at /data/src/10.1/sql/sql_connect.cc:1350
#16 0x00007fd9a978aba9 in handle_one_connection (arg=0x7fd983356070) at /data/src/10.1/sql/sql_connect.cc:1262
#17 0x00007fd9a8d560a4 in start_thread (arg=0x7fd9aa58cb00) at pthread_create.c:309
#18 0x00007fd9a6f0e87d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111



 Comments   
Comment by Sergei Golubchik [ 2016-07-25 ]

The fix for the first crash:

rename_table_in_stat_tables() was destroying the existing error state
    
diff --git a/sql/sql_statistics.cc b/sql/sql_statistics.cc
index 83c7db8..1c19d0d 100644
--- a/sql/sql_statistics.cc
+++ b/sql/sql_statistics.cc
@@ -3393,15 +3393,16 @@ int rename_table_in_stat_tables(THD *thd, LEX_STRING *db
   TABLE *stat_table;
   TABLE_LIST tables[STATISTICS_TABLES];
   Open_tables_backup open_tables_backup;
-  int rc= 0;
+  int rc;
 
   DBUG_ENTER("rename_table_in_stat_tables");
    
-  if (open_stat_tables(thd, tables, &open_tables_backup, TRUE))
-  {
-    thd->clear_error();
-    DBUG_RETURN(rc);
-  }
+  Dummy_error_handler deh; // suppress errors from open_stat_tables()
+  thd->push_internal_handler(&deh);
+  rc= open_stat_tables(thd, tables, &open_tables_backup, TRUE);
+  thd->pop_internal_handler();
+  if (rc)
+    DBUG_RETURN(0); // not an error
 
   save_binlog_format= thd->set_current_stmt_binlog_format_stmt();

Comment by Alexey Botchkov [ 2016-11-02 ]

Patch proposal
http://lists.askmonty.org/pipermail/commits/2016-November/010048.html

Note it includes Your fix for the part1 along somehow reworked.

Comment by Alexey Botchkov [ 2016-12-06 ]

The patch uses Table_check_intact
http://lists.askmonty.org/pipermail/commits/2016-December/010224.html

Comment by Sergei Golubchik [ 2016-12-06 ]

review sent. if you agree with the suggested change and it'll work, then ok to push, no need for another review.

Comment by Alexey Botchkov [ 2016-12-07 ]

http://lists.askmonty.org/pipermail/commits/2016-December/010231.html

Comment by Sergei Golubchik [ 2016-12-07 ]

ok to push

Generated at Thu Feb 08 07:42:12 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.