MySQL Bugs: #25092: MySQL key list becomes corrupted on 64bit linux on drop index

Bug #25092	MySQL key list becomes corrupted on 64bit linux on drop index
Submitted:	15 Dec 2006 12:20	Modified:	4 Jun 2007 13:44
Reporter:	Jan Lindström	Email Updates:
Status:	No Feedback	Impact on me:	None
Category:	MySQL Server	Severity:	S1 (Critical)
Version:	5.0 & 5.1	OS:	Any (AMD Linux)
Assigned to:		CPU Architecture:	Any

Description:
Try following SQL-queries

mysql> create table fm (s1 int, s2 int) engine=innodb;
Query OK, 0 rows affected (3.14 sec)

mysql> create index ifm1 on fm (s1);
Query OK, 0 rows affected (2.89 sec)
Records: 0  Duplicates: 0  Warnings: 0

mysql> create index ifm2 on fm (s1);
Query OK, 0 rows affected (2.50 sec)
Records: 0  Duplicates: 0  Warnings: 0

mysql> drop index ifm2 on fm;

Now in the gdb you can see that thd->lex->key_list is corrupted. List claims to contain 1 item but pointer to that item is corrupted:

Breakpoint 1, ha_innobase::create (this=0x1ec5d28, name=0x456939e0 "./test/#sql-2c96_1.frm
", form=0x45692e40, create_info=0x45694b40) at ha_innodb.cc:4569
(gdb) next
(gdb) p thd->lex->key_list
$20 = {<base_list> = {<Sql_alloc> = {<No data fields>}, first = 0x1ec8e40, last = 0x1ec8e4
0, elements = 1}, <No data fields>}
(gdb) p *thd->lex->key_list->first
$21 = {<Sql_alloc> = {<No data fields>}, next = 0xb, info = 0x400004008}

Now if you dry to create indexes based on this list (e.g. foreign keys) you will see a crash.

32bit linux seems to be ok, similarly 32bit and 64bit windows.

How to repeat:
create table fm (s1 int, s2 int) engine=innodb;
create index ifm1 on fm (s1);
create index ifm2 on fm (s1);
drop index ifm2 on fm;

Thank you for a problem report, and sorry for a delay with its processing. 

I can not get any problems with foreign keys, neither on 32-bit nor on 64-bit Linux with latest 5.0.36-BK:

mysqldev@rh-x86-64:~/valeriy/dbs/5.0> bin/mysql -uroot --socket=/tmp/valeriy.so
ck test
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 1
Server version: 5.0.36 Source distribution

Type 'help;' or '\h' for help. Type '\c' to clear the buffer.

mysql> create table fm (s1 int, s2 int) engine=innodb;
ifm1 on fm (s1);
create index ifm2 on fm (s1);
drop index ifQuery OK, 0 rows affected (0.17 sec)

mysql> create index ifm1 on fm (s1);
m2 on fm;Query OK, 0 rows affected (0.17 sec)
Records: 0  Duplicates: 0  Warnings: 0

mysql> create index ifm2 on fm (s1);
Query OK, 0 rows affected (0.10 sec)
Records: 0  Duplicates: 0  Warnings: 0

mysql> drop index ifm2 on fm;
Query OK, 0 rows affected (0.18 sec)
Records: 0  Duplicates: 0  Warnings: 0

mysql> create table tfk(c1 int, key(c1), foreign key k1(c1) references fm(s1));
Query OK, 0 rows affected (0.11 sec)

mysql> exit
Bye
mysqldev@rh-x86-64:~/valeriy/dbs/5.0> uname -a
Linux rh-x86-64.mysql.com 2.6.9-34.0.2.EL #1 Fri Jun 30 10:22:45 EDT 2006 x86_64
 x86_64 x86_64 GNU/Linux

Any your ideas on how to demonstrate the result of corruption you suspected are greatly appreciated.

Using mysql-5.0.34 l2x 32-bit and following simple test case:

drop table if exists bug28_a, bug28_b cascade

CREATE TABLE bug28_a
(
  a_id INT NOT NULL,
  PRIMARY KEY (a_id)
) engine=soliddb

CREATE TABLE bug28_b
(
  b2_id INT NOT NULL,
  b_id INT NOT NULL,
  a_id INT NOT NULL,
  PRIMARY KEY (b_id),
  KEY b2_id_key (b2_id),
  FOREIGN KEY (a_id)
    REFERENCES bug28_a (a_id)
    ON UPDATE RESTRICT
    ON DELETE RESTRICT
) engine=soliddb

DROP INDEX b2_id_key on bug28_b

Now on ::create() we see:

Breakpoint 1, ha_soliddb::create (this=0x96ea910, name=0x92ada3a8 "./test/#sql-c95_1.frm", table_arg=0x92ad98c0, create_info=0x92adb32c) at ha_soliddb.cc:11637
(gdb) c

Breakpoint 2, solid_check_fkeys (thd=0x96d8ed8, table=0x92ad98c0, table_name=0x93226c8c "bug28_b", n_fkeys=0x92ad969c) at ha_soliddb.cc:10846
(
(gdb) p thd->lex->key_list.elements
$7 = 4

        List_iterator<Key> key_iterator(thd->lex->key_list);
0852 
0853         *n_fkeys = 0;
0854         keys = thd->lex->key_list.elements;
0855 
0856         while(i < keys) {
0857             key = key_iterator++;

(gdb) p *key
Cannot access memory at address 0x40

Thus key list contains 4 elements but the first element is already corrupted. Similar results can be obtained using innodb storage engine.

Please, try to repeat with a newer versions, 5.0.37/5.0.40 and/or 5.1.17 and InnoDB. Inform about the results.

No feedback was provided for this bug for over a month, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".