Uploaded image for project: 'MariaDB Server'
  1. MariaDB Server
  2. MDEV-10495

InnoDB: Failing assertion: !index->to_be_dropped in file handler0alter.cc line 3490

Details

    Description

      Note: this ugly test is only to reproduce the failure, please don't put it into the test suite, create a sensible one instead when the nature of the problem is known.

      Run with --repeat=N

      --source include/have_innodb.inc
       
      SET GLOBAL lock_wait_timeout = 3;
       
      --connect (con11,127.0.0.1,root,,test)
      --connect (con13,127.0.0.1,root,,test)
      --connect (con14,127.0.0.1,root,,test)
       
      --connection con13
      	CREATE TABLE IF NOT EXISTS t1 (col1 INT, col2 INT, col3 INT, col4 TEXT, KEY ftidx(col4(40))) ENGINE = InnoDB;
      --error ER_CANT_DROP_FIELD_OR_KEY
      	ALTER TABLE t1 DROP KEY idx;
       
      --connection con14
      --send
      	ALTER TABLE t1 ADD KEY idx ( col4(10), col2 ) /* QUERY_NO 3188 CON_ID 14 */;
      --connection con13
      --error ER_PARSE_ERROR
      	CREATE OR REPLACE VIEW v1 AS SYNTAX ERROR;
          START TRANSACTION;
      --send
      	INSERT INTO t1 (col1,col2,col3,col4) VALUES ( 4, 3, 4, REPEAT(CAST(4 AS CHAR(1)),@fill_amount));
      --connection con11
      --connection con14
      --error ER_LOCK_WAIT_TIMEOUT
      --reap
      --send
      	ALTER TABLE t1 DROP KEY ftidx, ADD KEY idx ( col4(10), col2 ) /* QUERY_NO 4164 CON_ID 14 */;
      --connection con11
      --send
      	ALTER TABLE t1 ADD UNIQUE KEY uidx ( col4(10), col2 ) /* QUERY_NO 4644 CON_ID 11 */;
       
      --connection con13
      --error 0,ER_LOCK_WAIT_TIMEOUT
      --reap
      --disconnect con13
       
      --connection con14
      --error 0,ER_LOCK_WAIT_TIMEOUT,ER_INDEX_CORRUPT
      --reap
      --disconnect con14
       
      --connection con11
      --error 0,ER_LOCK_WAIT_TIMEOUT
      --reap
      --disconnect con11
       
      --connection default
       
      DROP TABLE t1;
      SET GLOBAL lock_wait_timeout = DEFAULT;
      

      Stack trace from 10.0 commit b5fb2a685b6ec67d37033b020a8145d1aac1fc93

      2016-08-04 02:14:39 7f1f112a3700  InnoDB: Assertion failure in thread 139771408692992 in file handler0alter.cc line 3490
      InnoDB: Failing assertion: !index->to_be_dropped
      

      #5  0x00007f1f0f038448 in __GI_abort () at abort.c:89
      #6  0x00007f1f07b668b9 in ha_innodb::prepare_inplace_alter_table (this=0x7f1efc88b088, altered_table=0x7f1efc45f070, ha_alter_info=0x7f1f112a0270) at /data/src/10.0/storage/innobase/handler/handler0alter.cc:3490
      #7  0x000000000083a3f1 in handler::ha_prepare_inplace_alter_table (this=0x7f1efc88b088, altered_table=0x7f1efc45f070, ha_alter_info=0x7f1f112a0270) at /data/src/10.0/sql/handler.cc:4169
      #8  0x00000000006fa8ed in mysql_inplace_alter_table (thd=0x7f1f03768070, table_list=0x7f1efc4241e0, table=0x7f1efc955c70, altered_table=0x7f1efc45f070, ha_alter_info=0x7f1f112a0270, inplace_supported=HA_ALTER_INPLACE_NO_LOCK_AFTER_PREPARE, target_mdl_request=0x7f1f1129fcc0, alter_ctx=0x7f1f112a0850) at /data/src/10.0/sql/sql_table.cc:7062
      #9  0x00000000006fef73 in mysql_alter_table (thd=0x7f1f03768070, new_db=0x7f1efc4247c0 "test", new_name=0x0, create_info=0x7f1f112a14f0, table_list=0x7f1efc4241e0, alter_info=0x7f1f112a1460, order_num=0, order=0x0, ignore=false) at /data/src/10.0/sql/sql_table.cc:8885
      #10 0x0000000000766713 in Sql_cmd_alter_table::execute (this=0x7f1efc4248c8, thd=0x7f1f03768070) at /data/src/10.0/sql/sql_alter.cc:312
      #11 0x000000000064e9eb in mysql_execute_command (thd=0x7f1f03768070) at /data/src/10.0/sql/sql_parse.cc:5115
      #12 0x0000000000651e16 in mysql_parse (thd=0x7f1f03768070, rawbuf=0x7f1efc424088 "ALTER TABLE t1 ADD UNIQUE KEY uidx ( col4(10), col2 ) /* QUERY_NO 4644 CON_ID 11 */", length=83, parser_state=0x7f1f112a2650) at /data/src/10.0/sql/sql_parse.cc:6575
      #13 0x0000000000644922 in dispatch_command (command=COM_QUERY, thd=0x7f1f03768070, packet=0x7f1f0376e071 "ALTER TABLE t1 ADD UNIQUE KEY uidx ( col4(10), col2 ) /* QUERY_NO 4644 CON_ID 11 */", packet_length=83) at /data/src/10.0/sql/sql_parse.cc:1309
      #14 0x0000000000643be5 in do_command (thd=0x7f1f03768070) at /data/src/10.0/sql/sql_parse.cc:999
      #15 0x0000000000761e66 in do_handle_one_connection (thd_arg=0x7f1f03768070) at /data/src/10.0/sql/sql_connect.cc:1378
      #16 0x0000000000761bd8 in handle_one_connection (arg=0x7f1f03768070) at /data/src/10.0/sql/sql_connect.cc:1293
      #17 0x00000000009fa3a0 in pfs_spawn_thread (arg=0x7f1f03705e70) at /data/src/10.0/storage/perfschema/pfs.cc:1860
      #18 0x00007f1f10f320a4 in start_thread (arg=0x7f1f112a3700) at pthread_create.c:309
      #19 0x00007f1f0f0ea87d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111
      

      Trying to get some variables.
      Some pointers may be invalid and cause the dump to abort.
      Query (0x7f1efc424088): ALTER TABLE t1 ADD UNIQUE KEY uidx ( col4(10), col2 ) /* QUERY_NO 4644 CON_ID 11 */
      Connection ID (thread ID): 11
      Status: NOT_KILLED
      

      10.2 is also affected.

      Attachments

        Activity

          Could not repeat with: MySQL Version 5.6.32

          jplindst Jan Lindström (Inactive) added a comment - Could not repeat with: MySQL Version 5.6.32

          Problem is that InnoDB returns HA_ALTER_INPLACE_NO_LOCK_AFTER_PREPARE after ha_innobase::prepare_inplace_alter_table in case of
          ALTER TABLE [ADD|DROP] index. This leads MDL lock downgrade to table>mdl_ticket>downgrade_lock(MDL_SHARED_UPGRADABLE). Here is what happens: Lets assume we have ALTER TABLE t DROP KEY a, in ha_innobase::prepare_inplace_alter_table we mark all dropped indexes with index->to_be_dropped = 1. While we are in this function all concurrent alter tables would need to wait MDL-lock. When we return MDL-lock is downgraded and concurrent ALTER TABLE t ADD KEY b is possible to start to do ha_innobase::prepare_inplace_alter_table() leading to this debug assertion.
          This is GA-product so not sure if it is good idea not to allow to do MDL-lock downgrade after ha_innobase::prepare_inplace_alter_table?
          Possible better solution would be return a error from ALTER TABLE ADD KEY if any of the indexes are marked as to_be_dropped ?

          Assigning to serg for comment.

          jplindst Jan Lindström (Inactive) added a comment - - edited Problem is that InnoDB returns HA_ALTER_INPLACE_NO_LOCK_AFTER_PREPARE after ha_innobase::prepare_inplace_alter_table in case of ALTER TABLE [ADD|DROP] index . This leads MDL lock downgrade to table>mdl_ticket>downgrade_lock(MDL_SHARED_UPGRADABLE) . Here is what happens: Lets assume we have ALTER TABLE t DROP KEY a , in ha_innobase::prepare_inplace_alter_table we mark all dropped indexes with index->to_be_dropped = 1 . While we are in this function all concurrent alter tables would need to wait MDL-lock. When we return MDL-lock is downgraded and concurrent ALTER TABLE t ADD KEY b is possible to start to do ha_innobase::prepare_inplace_alter_table() leading to this debug assertion. This is GA-product so not sure if it is good idea not to allow to do MDL-lock downgrade after ha_innobase::prepare_inplace_alter_table ? Possible better solution would be return a error from ALTER TABLE ADD KEY if any of the indexes are marked as to_be_dropped ? Assigning to serg for comment.

          what does 5.6 do differently? why does it not happen there?

          serg Sergei Golubchik added a comment - what does 5.6 do differently? why does it not happen there?

          Could not repeat after a lot of repeats using 10.0.35.

          jplindst Jan Lindström (Inactive) added a comment - Could not repeat after a lot of repeats using 10.0.35.

          The failure stopped happening after this commit in 10.0 (released in 10.0.29):

          commit f0c19b6a57b699d113e3ae4a67920924bbecae45
          Author: Marko Mäkelä
          Date:   Thu Jan 5 20:13:34 2017 +0200
           
              MDEV-11730 Memory leak in innodb.innodb_corrupt_bit
              
              Memory was leaked when ALTER TABLE is attempted on a table
              that contains corrupted indexes.
              The memory leak was reported by AddressSanitizer for the test
              innodb.innodb_corrupt_bit. The leak was introduced into
              MariaDB Server 10.0.26, 10.1.15, 10.2.1 by the following:
              
              commit c081c978a2c83b9dc9efa84414cf40232460987d
              Merge: 1d21b221552 a482e76e65a
              Author: Sergei Golubchik <serg@mariadb.org>
              Date:   Tue Jun 21 14:11:02 2016 +0200
              
                 Merge branch '5.5' into bb-10.0
           
          diff --git a/storage/innobase/handler/handler0alter.cc b/storage/innobase/handler/handler0alter.cc
          index 3164879..89a58d8 100644
          --- a/storage/innobase/handler/handler0alter.cc
          +++ b/storage/innobase/handler/handler0alter.cc
          @@ -3890,7 +3890,7 @@ ha_innobase::prepare_inplace_alter_table(
                                                  index->name, TRUE);
           
                                          my_error(ER_INDEX_CORRUPT, MYF(0), index_name);
          -                               DBUG_RETURN(true);
          +                               goto err_exit;
                                  }
                          }
                  }
          diff --git a/storage/xtradb/handler/handler0alter.cc b/storage/xtradb/handler/handler0alter.cc
          index c5ac48d..7c17e93 100644
          --- a/storage/xtradb/handler/handler0alter.cc
          +++ b/storage/xtradb/handler/handler0alter.cc
          @@ -3904,7 +3904,7 @@ ha_innobase::prepare_inplace_alter_table(
                                                  index->name, TRUE);
           
                                          my_error(ER_INDEX_CORRUPT, MYF(0), index_name);
          -                               DBUG_RETURN(true);
          +                               goto err_exit;
                                  }
                          }
                  }
          

          jplindst, marko, would you say it was a real fix for this problem, or has it just changed something to make the test case irrelevant?

          elenst Elena Stepanova added a comment - The failure stopped happening after this commit in 10.0 (released in 10.0.29): commit f0c19b6a57b699d113e3ae4a67920924bbecae45 Author: Marko Mäkelä Date: Thu Jan 5 20:13:34 2017 +0200   MDEV-11730 Memory leak in innodb.innodb_corrupt_bit Memory was leaked when ALTER TABLE is attempted on a table that contains corrupted indexes. The memory leak was reported by AddressSanitizer for the test innodb.innodb_corrupt_bit. The leak was introduced into MariaDB Server 10.0.26, 10.1.15, 10.2.1 by the following: commit c081c978a2c83b9dc9efa84414cf40232460987d Merge: 1d21b221552 a482e76e65a Author: Sergei Golubchik <serg@mariadb.org> Date: Tue Jun 21 14:11:02 2016 +0200 Merge branch '5.5' into bb-10.0   diff --git a/storage/innobase/handler/handler0alter.cc b/storage/innobase/handler/handler0alter.cc index 3164879..89a58d8 100644 --- a/storage/innobase/handler/handler0alter.cc +++ b/storage/innobase/handler/handler0alter.cc @@ -3890,7 +3890,7 @@ ha_innobase::prepare_inplace_alter_table( index->name, TRUE); my_error(ER_INDEX_CORRUPT, MYF(0), index_name); - DBUG_RETURN(true); + goto err_exit; } } } diff --git a/storage/xtradb/handler/handler0alter.cc b/storage/xtradb/handler/handler0alter.cc index c5ac48d..7c17e93 100644 --- a/storage/xtradb/handler/handler0alter.cc +++ b/storage/xtradb/handler/handler0alter.cc @@ -3904,7 +3904,7 @@ ha_innobase::prepare_inplace_alter_table( index->name, TRUE); my_error(ER_INDEX_CORRUPT, MYF(0), index_name); - DBUG_RETURN(true); + goto err_exit; } } } jplindst , marko , would you say it was a real fix for this problem, or has it just changed something to make the test case irrelevant?

          Tried to repeat with provided test case as well as using debug sync but failed.

          jplindst Jan Lindström (Inactive) added a comment - Tried to repeat with provided test case as well as using debug sync but failed.

          People

            jplindst Jan Lindström (Inactive)
            elenst Elena Stepanova
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved:

              Git Integration

                Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.