MySQL Bugs: #75187: Crash when importing tablespace with a page size of >16k

Bug #75187	Crash when importing tablespace with a page size of >16k
Submitted:	11 Dec 2014 20:26	Modified:	23 Dec 2014 13:05
Reporter:	Daniël van Eeden (OCA)	Email Updates:
Status:	Won't fix	Impact on me:	None
Category:	MySQL Server: InnoDB storage engine	Severity:	S3 (Non-critical)
Version:	5.6.22	OS:	Any
Assigned to:		CPU Architecture:	Any
Tags:	compatibility, crash, innodb_page_size

Description:
InnoDB crashes when you try to import a tablespace with a page size of more that 16k.

I know 32k page size is just a labs release, so consider making page sizes of more that 16k to require innodb file format (C)heetah so older (<=5.6) servers know they're reading something incompatible. Also consider innodbchecksum and MEB.

2014-12-11 21:16:10 7f050f978780  InnoDB: Assertion failure in thread 139659713152896 in file fsp0fsp.ic line 170
InnoDB: Failing assertion: page_size <= (1 << 14)
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
20:16:10 UTC - mysqld got signal 6 ;
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.

key_buffer_size=8388608
read_buffer_size=131072
max_used_connections=0
max_threads=151
thread_count=0
connection_count=0
It is possible that mysqld could use up to 
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 68249 K  bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

Thread pointer: 0x0
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
stack_bottom = 0 thread_stack 0x40000
/home/dveeden/opt/mysql/5.6.22/bin/mysqld(my_print_stacktrace+0x47)[0xaa526c]
/home/dveeden/opt/mysql/5.6.22/bin/mysqld(handle_fatal_signal+0x3c2)[0x72266a]
/lib/x86_64-linux-gnu/libpthread.so.0(+0xfc90)[0x7f050ef3bc90]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0x37)[0x7f050e371d27]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x148)[0x7f050e373418]
/home/dveeden/opt/mysql/5.6.22/bin/mysqld[0xcf95fa]
/home/dveeden/opt/mysql/5.6.22/bin/mysqld[0xcfcd42]
/home/dveeden/opt/mysql/5.6.22/bin/mysqld[0xcfcef3]
/home/dveeden/opt/mysql/5.6.22/bin/mysqld[0xd00ef6]
/home/dveeden/opt/mysql/5.6.22/bin/mysqld[0xd0141e]
/home/dveeden/opt/mysql/5.6.22/bin/mysqld[0xd01c3a]
/home/dveeden/opt/mysql/5.6.22/bin/mysqld[0xb3a8d2]
/home/dveeden/opt/mysql/5.6.22/bin/mysqld[0xb3ada2]
/home/dveeden/opt/mysql/5.6.22/bin/mysqld[0xc14ca3]
/home/dveeden/opt/mysql/5.6.22/bin/mysqld[0xac857b]
/home/dveeden/opt/mysql/5.6.22/bin/mysqld(_Z24ha_initialize_handlertonP13st_plugin_int+0xec)[0x631f84]
/home/dveeden/opt/mysql/5.6.22/bin/mysqld[0x7e2a89]
/home/dveeden/opt/mysql/5.6.22/bin/mysqld(_Z11plugin_initPiPPci+0x6f9)[0x7e347c]
/home/dveeden/opt/mysql/5.6.22/bin/mysqld[0x61c90b]
/home/dveeden/opt/mysql/5.6.22/bin/mysqld(_Z11mysqld_mainiPPc+0x4e8)[0x61d689]
/home/dveeden/opt/mysql/5.6.22/bin/mysqld(main+0x20)[0x613846]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5)[0x7f050e35cec5]
/home/dveeden/opt/mysql/5.6.22/bin/mysqld[0x613759]
The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.
141211 21:16:10 mysqld_safe mysqld from pid file /home/dveeden/sandboxes/msb_5_6_22/data/mysql_sandbox5622.pid ended

How to repeat:
On 5.7.5-labs-preview:
CREATE TABLE `t1` (
  `id` int(11) DEFAULT NULL
) ENGINE=InnoDB DEFAULT CHARSET=latin1 ROW_FORMAT=DYNAMIC

Then on 5.6.22:
mysql> CREATE TABLE `t1` (
    ->   `id` int(11) DEFAULT NULL
    -> ) ENGINE=InnoDB DEFAULT CHARSET=latin1 ROW_FORMAT=DYNAMIC
    -> ;
Query OK, 0 rows affected (0.02 sec)

mysql> alter table t1 discard tablespace;
Query OK, 0 rows affected (0.01 sec)

mysql> alter table t1 import tablespace;
ERROR 2013 (HY000): Lost connection to MySQL server during query

Suggested fix:
Don't crash, but display an error: 'Tablespace has unsupported page size (32k)'

If both the .ibd and .cfg are copied then it's handled correctly:
ERROR 1808 (HY000): Schema mismatch (Tablespace to be imported has a different page size than this server. Server page size is 16384, whereas tablespace page size is 32768)

If only the .ibd is copied it will crash on import and keep crashing on restart.

Also the crash only happens on debug builds.

On a non-debug 5.6.21:
2014-12-14 10:47:48 31427 [ERROR] InnoDB: Page size 32768 of ibd file is not the same as the server page size 16384
2014-12-14 10:47:48 31427 [Note] InnoDB: Discarding tablespace of table "test"."t1": Data structure corruption

This is what happens on restart of 5.6.22-dbg after a crash on import of a 32k ibd file (w/o .cfg).

(gdb) bt
#0  0x00007f1d34b5a2c1 in __pthread_kill (threadid=<optimized out>, signo=6) at ../nptl/sysdeps/unix/sysv/linux/pthread_kill.c:61
#1  0x0000000000aa530e in my_write_core (sig=6) at /home/dveeden/dev/mysql-server/mysys/stacktrace.c:422
#2  0x000000000072281a in handle_fatal_signal (sig=6) at /home/dveeden/dev/mysql-server/sql/signal_handler.cc:230
#3  <signal handler called>
#4  0x00007f1d33f92d27 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
#5  0x00007f1d33f94418 in __GI_abort () at abort.c:89
#6  0x0000000000cf95fa in fsp_flags_get_page_size (flags=417) at /home/dveeden/dev/mysql-server/storage/innobase/include/fsp0fsp.ic:170
#7  0x0000000000cfcd42 in fil_check_first_page (page=0x29e8000 "\335lH\202") at /home/dveeden/dev/mysql-server/storage/innobase/fil/fil0fil.cc:1989
#8  0x0000000000cfcef3 in fil_read_first_page (data_file=12, one_read_already=0, flags=0x7fffdf2aa128, space_id=0x7fffdf2aa120, 
    min_flushed_lsn=0x7fffdf2aa118, max_flushed_lsn=0x7fffdf2aa118) at /home/dveeden/dev/mysql-server/storage/innobase/fil/fil0fil.cc:2066
#9  0x0000000000d00ef6 in fil_validate_single_table_tablespace (tablename=0x29d1108 "test/t1", fsp=0x7fffdf2aa0f0)
    at /home/dveeden/dev/mysql-server/storage/innobase/fil/fil0fil.cc:4199
#10 0x0000000000d0141e in fil_load_single_table_tablespace (dbname=0x7fffdf2aa1c0 "test", filename=0x7fffdf2ab190 "t1.ibd")
    at /home/dveeden/dev/mysql-server/storage/innobase/fil/fil0fil.cc:4351
#11 0x0000000000d01c3a in fil_load_single_table_tablespaces () at /home/dveeden/dev/mysql-server/storage/innobase/fil/fil0fil.cc:4710
#12 0x0000000000b3a8d2 in recv_init_crash_recovery () at /home/dveeden/dev/mysql-server/storage/innobase/log/log0recv.cc:2974
#13 0x0000000000b3ada2 in recv_recovery_from_checkpoint_start_func (min_flushed_lsn=1643715, max_flushed_lsn=1643715)
    at /home/dveeden/dev/mysql-server/storage/innobase/log/log0recv.cc:3266
#14 0x0000000000c14ca3 in innobase_start_or_create_for_mysql () at /home/dveeden/dev/mysql-server/storage/innobase/srv/srv0start.cc:2406
#15 0x0000000000ac857b in innobase_init (p=0x2397760) at /home/dveeden/dev/mysql-server/storage/innobase/handler/ha_innodb.cc:3282
#16 0x0000000000631f84 in ha_initialize_handlerton (plugin=0x238db90) at /home/dveeden/dev/mysql-server/sql/handler.cc:662
#17 0x00000000007e2a89 in plugin_initialize (plugin=0x238db90) at /home/dveeden/dev/mysql-server/sql/sql_plugin.cc:1137
#18 0x00000000007e347c in plugin_init (argc=0x17fe788 <remaining_argc>, argv=0x229b1d8, flags=0) at /home/dveeden/dev/mysql-server/sql/sql_plugin.cc:1431
#19 0x000000000061c90b in init_server_components () at /home/dveeden/dev/mysql-server/sql/mysqld.cc:4849
#20 0x000000000061d689 in mysqld_main (argc=20, argv=0x229b1d8) at /home/dveeden/dev/mysql-server/sql/mysqld.cc:5444
#21 0x0000000000613846 in main (argc=9, argv=0x7fffdf2b0b98) at /home/dveeden/dev/mysql-server/sql/main.cc:25

flags=417 seems to be 1=dynamic + 32=dynamic_file_per_table + 384=32k
This is based on http://dev.mysql.com/doc/refman/5.7/en/innodb-sys-tablespaces-table.html and the assumption that 384 probably means 32k.

This doesn't include the discarded flag.

The discarded flags seems to be in
"Table Flags set number 2. These flags will be stored in SYS_TABLES.MIX_LEN"

The MIX_LEN is not exposed in INFORMATION_SCHEMA.INNODB_SYS_TABLES. I expect it to be set to 48 (32=discarded, 16=file_per_table).

Hello Daniël,

Thank you for the report and test case.
Confirmed that when copying Tablespaces(5.7.5-labs-preview with --innodb_page_size=32k) to Another Server(5.6.22-enterprise-commercial-advanced-debug) debug builds of target instance(5.6.22) asserted.

Imho doc warns when importing a tablespace, the page size must match the page size of the importing instance, pls see http://dev.mysql.com/doc/refman/5.6/en/tablespace-copying.html

But still it should not assert when mismatches the same.

Thanks,
Umesh

Close the bug for the following reasons:
1. Import a table space from 5.7 to 5.6, error and crash is acceptable(we
don't support forward compatibility);
2. The crash happens only in 5.6 debug build;
3. The crash doesn't happens in 5.7.