Bug #60042 | Crash in ha_innobase::open | ||
---|---|---|---|
Submitted: | 9 Feb 2011 9:50 | Modified: | 5 Jan 2012 0:19 |
Reporter: | Roel Van de Paar | Email Updates: | |
Status: | Closed | Impact on me: | |
Category: | MySQL Server: InnoDB storage engine | Severity: | S1 (Critical) |
Version: | 5.6.2-m5 (mysql-next-mr-opt-backporting) | OS: | Any |
Assigned to: | Jimmy Yang | CPU Architecture: | Any |
[9 Feb 2011 9:50]
Roel Van de Paar
[9 Feb 2011 10:08]
Roel Van de Paar
mysql> show tables; ERROR 2006 (HY000): MySQL server has gone away Same crash. So must be some corruption that happened. This was after bug #60038.
[10 Feb 2011 10:51]
Jimmy Yang
A previous crash has left the table definition in MySQL and InnoDB inconsistent: <Roel> Version: '5.6.2-m5-debug' socket: '/mysql2/mysql-5.6.2-m5-linux-x86_64-debug/socket-5621.sock' port: 5621 Source distribution <Roel> 110209 21:00:13 [ERROR] Table ./test/@0I@00b7D@002c@0016@002c@0I@4vO@0J@00basO@0J@203a@0018K@0J@2030w@0J@00bf@0I@201e@0028n@0I@2122X@0J@2021@ <Roel> 0J@00a2@003d@0J@00a2@0I@201c@0011V9@002a8 has a primary key in InnoDB data dictionary, but not in MySQL! <Roel> 110209 21:00:13 - mysqld got signal 11 ; So MySQL do not have any index defined, but InnoDB has a primary index "idx1". <Roel> (gdb) p table->key_info <Roel> $3 = (KEY *) 0x0 <Roel> (gdb) p table->s->keys <Roel> $9 = 0 After printing the message, when we reference table->key_info[0].key_length, it will trigger sig 11 since table->key_info is NULL. Fix will be check null for table->key_info before it continue.
[15 Feb 2011 13:07]
Jimmy Yang
As above analysis, this can be repro-ed using a debugger: mysql> create table aa(a int not NULL) engine = innodb; Query OK, 0 rows affected (0.13 sec) Put breakpoint at ha_innobase::add_index and let following create index finishing ha_innobase::add_index(). Before it return to MySQL server, kill the server Breakpoint 3, ha_innobase::add_index (this=0x90be940, table=0x90be268, key_info=0x9093588, num_of_keys=1) at /home/jy/work2/mysql-trunk-innodb3/storage/innobase/handler/handler0alter.cc:1034 1034 DBUG_RETURN(error); (gdb) p error $2 = 0 (gdb) kill Kill the program being debugged? (y or n) y mysql> create unique index idx on aa(a); ERROR 2013 (HY000): Lost connection to MySQL server during query This is to create a primary index. But it is successful in InnoDB but failed to do so in MySQL server, and we had a mismatch. Reboot the server, and access the table: mysql> select * from aa; Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xb1c28b70 (LWP 32249)] 0x08594f5e in ha_innobase::open (this=0x903f9f0, name=0x8fff5c0 "./test/aa", mode=2, test_if_locked=2) at /home/jy/work2/mysql-trunk-innodb3/storage/innobase/handler/ha_innodb.cc:4057 4057 ref_length = table->key_info[0].key_length; (gdb) c Continuing. 110215 5:03:36 - mysqld got signal 11 ; This could be because you hit a bug. It is also possible that this binary or one of the libraries it was linked against is corrupt, improperly built, or misconfigured. This error can also be caused by malfunctioning hardware. We will try our best to scrape up some info that will hopefully help diagnose the problem, but since we have already crashed, something is definitely wrong and this may fail. ... stack_bottom = 0xb1c282f8 thread_stack 0x30000 /home/jy/work2/mysql-trunk-innodb3/bld/sql/mysqld(my_print_stacktrace+0x32)[0x84f30b9] /home/jy/work2/mysql-trunk-innodb3/bld/sql/mysqld(handle_segfault+0x2b1)[0x818434d] [0x294400] /home/jy/work2/mysql-trunk-innodb3/bld/sql/mysqld(_ZN7handler7ha_openEP5TABLEPKcii+0x114)[0x8356c10] /home/jy/work2/mysql-trunk-innodb3/bld/sql/mysqld(_Z21open_table_from_shareP3THDP11TABLE_SHAREPKcjjjP5TABLEb+0xa55)[0x82ad693] /home/jy/work2/mysql-trunk-innodb3/bld/sql/mysqld(_Z10open_tableP3THDP10TABLE_LISTP11st_mem_rootP18Open_table_context+0x101e)[0x81bb6ab] /home/jy/work2/mysql-trunk-innodb3/bld/sql/mysqld[0x81bd768]
[5 Jan 2012 0:19]
John Russell
Added to 5.6.3 changelog: If the MySQL Server crashed immediately after creating an InnoDB table, attempting to access the table after restart could cause another crash. The issue could occur if the server halted after InnoDB created the primary index for the table, but before the index definition was recorded in the MySQL metadata.