[MDEV-10495] InnoDB: Failing assertion: !index->to_be_dropped in file handler0alter.cc line 3490 Created: 2016-08-03  Updated: 2018-08-01  Resolved: 2018-08-01

Status: Closed
Project: MariaDB Server
Component/s: Storage Engine - InnoDB, Storage Engine - XtraDB
Affects Version/s: 10.0, 10.1
Fix Version/s: 10.0.29, 10.1.35

Type: Bug Priority: Major
Reporter: Elena Stepanova Assignee: Jan Lindström (Inactive)
Resolution: Fixed Votes: 0
Labels: None


 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.



 Comments   
Comment by Jan Lindström (Inactive) [ 2016-08-13 ]

Could not repeat with: MySQL Version 5.6.32

Comment by Jan Lindström (Inactive) [ 2016-08-16 ]

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.

Comment by Sergei Golubchik [ 2017-01-04 ]

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

Comment by Jan Lindström (Inactive) [ 2018-07-16 ]

Could not repeat after a lot of repeats using 10.0.35.

Comment by Elena Stepanova [ 2018-07-16 ]

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?

Comment by Jan Lindström (Inactive) [ 2018-08-01 ]

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

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