handle_fatal_signal (sig=11) in ha_innobase::check | handler/ha_innodb.cc:12244
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Percona Server moved to https://jira.percona.com/projects/PS |
Fix Released
|
High
|
Krunal Bauskar | ||
5.1 |
Invalid
|
Undecided
|
Unassigned | ||
5.5 |
Invalid
|
Undecided
|
Unassigned | ||
5.6 |
Fix Released
|
High
|
Krunal Bauskar |
Bug Description
** Testcase
DROP DATABASE test;CREATE DATABASE test;USE test;
set global innodb_
CREATE TABLE t1(c1 INT,c2 CHAR (1),c3 INT(1),c4 CHAR (1) KEY,c5 INT UNIQUE KEY,c6 FIXED(0,0) DEFAULT 3.141592);
TRUNCATE TABLE test.t1;
INSERT INTO t1 SELECT a,b+32 FROM t1;
check TABLE t1;
** Extra startup option
--log-bin=binlog
The attached tarball gives the testcase as an exact match of our system, including some handy utilities
$ vi {epoch}_mybase # Update base path in this file (the only change
required!). For non-binary distribution please update SOURCE_DIR location also.
$ ./{epoch}_init # Initializes the data dir
$ ./{epoch}_start # Starts mysqld
$ ./{epoch}_cl # To check mysqld is up
$ ./{epoch}_run # Run the testcase with pquery binary(produces
output)
$ vi /dev/shm/
$ ./{epoch}_gdb # Brings you to a gdb prompt attached to correct
mysqld
& generated core
$ ./{epoch}
standard and full var gdb stack traces
etc.
** GDB info
#0 0x00007fbb275bf771 in pthread_kill () from /lib64/
#1 0x0000000000abb48e in my_write_core (sig=11) at /mnt/workspace/
#2 0x00000000007312c3 in handle_fatal_signal (sig=11) at /mnt/workspace/
#3 <signal handler called>
#4 0x0000000000ae41df in ha_innobase::check (this=0x7fbb058
#5 0x000000000064717d in handler::ha_check (this=0x7fbb058
#6 0x00000000009a3700 in mysql_admin_
#7 0x00000000009a502e in Sql_cmd_
#8 0x00000000007eb7f9 in mysql_execute_
#9 0x00000000007ef059 in mysql_parse (thd=0x7fbb1577
#10 0x00000000007e0ecf in dispatch_command (command=COM_QUERY, thd=0x7fbb15773000, packet=
#11 0x00000000007dfded in do_command (thd=0x7fbb1577
#12 0x00000000007a7d0d in do_handle_
#13 0x00000000007a7815 in handle_
#14 0x0000000000dcc8c0 in pfs_spawn_thread (arg=0x7fbb20b4
#15 0x00007fbb275badf3 in start_thread () from /lib64/
#16 0x00007fbb262841ad in clone () from /lib64/libc.so.6
tags: | added: xtradb |
ha_innobase: :check( ) table api was using stale reference of table to check if table is corrupted.
Here is more easier way to understand it.
a. Truncate needs at-least 2 undo-slots to work. Anything less than it may cause truncate to fail. Truncate being ddl operation failure is non-recoverable (unless we do smart technique out-of-scope for now). This causes the table to mark as corrupt.
b. insert/dml operation post this will cause table to re-open which will invalidate the share->ib_table reference.
c. check table followed by this dml will have share->ib_table as invalid and so use of it will result in error.
Well failure of open should also invalidate the old handler instance that MySQL Server Layer is using for executing check table but that is different issue and may need to be fixed at generic level.
----------
Patch for this bug has been committed.
Pull Request: pr#144 ae67afd8a806a0e d581530f7e (pr merge 5b15dc40cf96671 f77ca0cd7ed81b9 67646e647d)
Commit: 14d5d9a94f2cac1