[MDEV-7049] MySQL#74585 - InnoDB: Failing assertion: *mbmaxlen < 5 in file ha_innodb.cc line 1904 Created: 2014-11-08  Updated: 2018-05-14  Resolved: 2018-01-22

Status: Closed
Project: MariaDB Server
Component/s: Storage Engine - InnoDB, Storage Engine - XtraDB
Affects Version/s: 5.5, 10.0
Fix Version/s: 5.5.60, 10.0.34, 10.1.31, 10.2.13, 10.3.5

Type: Bug Priority: Major
Reporter: Elena Stepanova Assignee: Marko Mäkelä
Resolution: Fixed Votes: 0
Labels: upstream, upstream-fixed

Issue Links:
Duplicate
is duplicated by MDEV-12680 Crash when CREATE TABLE t1 AS SELECT ... Closed
Relates
relates to MDEV-7057 Track most important upstream bugs wh... Closed

 Description   

Initially reported by Ramesh Sivaraman as http://bugs.mysql.com/bug.php?id=74585; refiling here to make it searchable in Jira and preserve the test case.

DROP DATABASE test;CREATE DATABASE test;USE test;
 
SET character_set_filesystem=filename;
 
SET @session_start_value=@@character_set_filesystem;
 
SET @@session.character_set_database=@session_start_value;
 
set character set default;
 
create temporary table v0as select 'This is temp. table' A;
 

InnoDB: Assertion failure in thread 140207163553536 in file ha_innodb.cc line 1904
 
InnoDB: Failing assertion: *mbmaxlen < 5
 

#5  0x00007f84843607c0 in *__GI_abort () at abort.c:92
 
#6  0x0000000000a015db in innobase_get_cset_width (cset=17, mbminlen=0x7f84862d54f8, mbmaxlen=0x7f84862d54f0) at 10.0/storage/xtradb/handler/ha_innodb.cc:1904
 
#7  0x0000000000c1ed5f in dtype_get_mblen (mtype=12, prtype=1114383, mbminlen=0x7f84862d54f8, mbmaxlen=0x7f84862d54f0) at 10.0/storage/xtradb/include/data0type.ic:96
 
#8  0x0000000000c209b0 in dict_mem_fill_column_struct (column=0x7f8470c60b78, col_pos=0, mtype=12, prtype=1114383, col_len=95) at 10.0/storage/xtradb/dict/dict0mem.cc:499
 
#9  0x0000000000c20224 in dict_mem_table_add_col (table=0x7f8470f4b978, heap=0x7f8470c29800, name=0x7f8472f8df49 "A", mtype=12, prtype=1114383, len=95) at 10.0/storage/xtradb/dict/dict0mem.cc:312
 
#10 0x0000000000a0ddc4 in create_table_def (trx=0x7f8470d54c78, form=0x7f84862d67c0, table_name=0x7f84862d58b0 "mysqld.1/#sql403c_3_0", temp_path=0x7f84862d5ab0 "/data/repo/bzr/10.0/mysql-test/var/tmp/mysqld.1/#sql403c_3_0", remote_path=0x7f84862d5cb0 "", flags=1, flags2=81) at 10.0/storage/xtradb/handler/ha_innodb.cc:9697
 
#11 0x0000000000a0f742 in ha_innobase::create (this=0x7f8470e0c088, name=0x7f84862d84c0 "/data/repo/bzr/10.0/mysql-test/var/tmp/mysqld.1/#sql403c_3_0", form=0x7f84862d67c0, create_info=0x7f84862d9cb0) at 10.0/storage/xtradb/handler/ha_innodb.cc:10616
 
#12 0x0000000000871070 in handler::ha_create (this=0x7f8470e0c088, name=0x7f84862d84c0 "/data/repo/bzr/10.0/mysql-test/var/tmp/mysqld.1/#sql403c_3_0", form=0x7f84862d67c0, info=0x7f84862d9cb0) at 10.0/sql/handler.cc:4285
 
#13 0x0000000000871f4d in ha_create_table (thd=0x7f847df0b070, path=0x7f84862d84c0 "/data/repo/bzr/10.0/mysql-test/var/tmp/mysqld.1/#sql403c_3_0", db=0x7f8470e1d788 "test", table_name=0x7f8470e1d178 "v0as", create_info=0x7f84862d9cb0, frm=0x7f84862d86d0) at 10.0/sql/handler.cc:4654
 
#14 0x000000000076b749 in rea_create_table (thd=0x7f847df0b070, frm=0x7f84862d86d0, path=0x7f84862d84c0 "/data/repo/bzr/10.0/mysql-test/var/tmp/mysqld.1/#sql403c_3_0", db=0x7f8470e1d788 "test", table_name=0x7f8470e1d178 "v0as", create_info=0x7f84862d9cb0, file=0x7f8470e14088, no_ha_create_table=false) at 10.0/sql/unireg.cc:378
 
#15 0x000000000072798e in create_table_impl (thd=0x7f847df0b070, orig_db=0x7f8470e1d788 "test", orig_table_name=0x7f8470e1d178 "v0as", db=0x7f8470e1d788 "test", table_name=0x7f8470e1d178 "v0as", path=0x7f84862d84c0 "/data/repo/bzr/10.0/mysql-test/var/tmp/mysqld.1/#sql403c_3_0", create_info=0x7f84862d9cb0, alter_info=0x7f84862d9c20, create_table_mode=1, is_trans=0x0, key_info=0x7f84862d86e8, key_count=0x7f84862d86e4, frm=0x7f84862d86d0) at 10.0/sql/sql_table.cc:4835
 
#16 0x0000000000727eb5 in mysql_create_table_no_lock (thd=0x7f847df0b070, db=0x7f8470e1d788 "test", table_name=0x7f8470e1d178 "v0as", create_info=0x7f84862d9cb0, alter_info=0x7f84862d9c20, is_trans=0x0, create_table_mode=1) at 10.0/sql/sql_table.cc:4949
 
#17 0x0000000000665686 in create_table_from_items (thd=0x7f847df0b070, create_info=0x7f84862d9cb0, create_table=0x7f8470e1d1b0, alter_info=0x7f84862d9c20, items=0x7f847df0f580, lock=0x7f84862d9878, hooks=0x7f84862d9850) at 10.0/sql/sql_insert.cc:3911
 
#18 0x0000000000665cf1 in select_create::prepare (this=0x7f8470e1d8a0, values=..., u=0x7f847df0ed80) at 10.0/sql/sql_insert.cc:4083
 
#19 0x00000000006affc9 in JOIN::prepare (this=0x7f8470e1d980, rref_pointer_array=0x7f847df0f6e0, tables_init=0x0, wild_num=0, conds_init=0x0, og_num=0, order_init=0x0, skip_order_by=false, group_init=0x0, having_init=0x0, proc_param_init=0x0, select_lex_arg=0x7f847df0f468, unit_arg=0x7f847df0ed80) at 10.0/sql/sql_select.cc:967
 
#20 0x00000000006b7d4d in mysql_select (thd=0x7f847df0b070, rref_pointer_array=0x7f847df0f6e0, tables=0x0, wild_num=0, fields=..., conds=0x0, og_num=0, order=0x0, group=0x0, having=0x0, proc_param=0x0, select_options=2416184064, result=0x7f8470e1d8a0, unit=0x7f847df0ed80, select_lex=0x7f847df0f468) at 10.0/sql/sql_select.cc:3286
 
#21 0x00000000006ae3f5 in handle_select (thd=0x7f847df0b070, lex=0x7f847df0ecb8, result=0x7f8470e1d8a0, setup_tables_done_option=0) at 10.0/sql/sql_select.cc:373
 
#22 0x000000000067c469 in mysql_execute_command (thd=0x7f847df0b070) at 10.0/sql/sql_parse.cc:2997
 
#23 0x000000000068586f in mysql_parse (thd=0x7f847df0b070, rawbuf=0x7f8470e1d088 "create temporary table v0as select 'This is temp. table' A", length=58, parser_state=0x7f84862da630) at 10.0/sql/sql_parse.cc:6407
 
#24 0x0000000000678652 in dispatch_command (command=COM_QUERY, thd=0x7f847df0b070, packet=0x7f8472ff2071 "create temporary table v0as select 'This is temp. table' A", packet_length=58) at 10.0/sql/sql_parse.cc:1299
 
#25 0x00000000006779f7 in do_command (thd=0x7f847df0b070) at 10.0/sql/sql_parse.cc:996
 
#26 0x00000000007944aa in do_handle_one_connection (thd_arg=0x7f847df0b070) at 10.0/sql/sql_connect.cc:1379
 
#27 0x00000000007941fd in handle_one_connection (arg=0x7f847df0b070) at 10.0/sql/sql_connect.cc:1293
 
#28 0x0000000000ccb4a6 in pfs_spawn_thread (arg=0x7f847dfd9df0) at 10.0/storage/perfschema/pfs.cc:1860
 
#29 0x00007f8485f0fb50 in start_thread (arg=<optimized out>) at pthread_create.c:304
 
#30 0x00007f848440720d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112

Stack trace from

 
revision-id: sergii@pisem.net-20141103164737-457hfby1eg82zol9
 
date: 2014-11-03 17:47:37 +0100
 
build-date: 2014-11-08 18:41:28 +0400
 
revno: 4471
 
branch-nick: 10.0



 Comments   
Comment by Daniel Black [ 2017-03-28 ]

Also in the same region of code http://bugs.mysql.com/?id=85661 - mariadb code is for innobase_get_cset_width is the same. 

ut_a(cset == 0);

Comment by Alexander Barkov [ 2017-05-04 ]

This script also makes the server crash:

CREATE OR REPLACE TABLE t1 AS SELECT char(100 using filename);

Comment by Daniel Black [ 2017-12-30 ]

Fixed in mysql per https://github.com/mysql/mysql-server/commit/02efde2650a22c8c70840975e9a524981b279307

Comment by Sergei Golubchik [ 2018-01-21 ]

We don't want to use this fix, it simply hides the "filename" charset from the user. But there are other charsets that have mbmaxlen == 5 (for example, gb18030).

Comment by Marko Mäkelä [ 2018-01-22 ]

danblack, I believe that the reason of the MySQL bug#85661 is that innobase_get_cset_width() fails to find a characterset-collation by a numeric identifier. Perhaps some collation has been removed or disabled in MySQL 5.7, or some loadable collations were used prior to upgrading and are not available after upgrading.

I will fix this issue by splitting the 5-bit field mbminmaxlen into two 3-bit fields mbminlen and mbmaxlen. With the 5-bit field, we can only represent a pair of values 0 to 4, because 4*5+4 = 24 fits in the range 0‥31. Changing the encoding to allow pairs of 0‥5 would extend the range to 0‥35, which cannot be encoded in the bitfield. Instead of extending mbminmaxlen to 6 bits, it is easier to have two bitfields mbminlen and mbmaxlen of 3 bits each. This only affects main-memory data structures, because InnoDB would persistently store the characterset-collation code as part of what it calls prtype.

Comment by Marko Mäkelä [ 2018-01-22 ]

Pushed to 5.5 and spent about 1 hour merging to 10.0 (work in progress).

Comment by Daniel Black [ 2018-01-22 ]

Ack. Thanks. I wouldn't have thought of it that way. Looks rather nice.

I was looking at a 10.2 fix of the following which still could apply and brings the number of points of duplication of this information down by one.

diff --git a/storage/innobase/include/data0type.h b/storage/innobase/include/data0type.h
 
index 35dcf2f3397..6b5c843e8cf 100644
 
--- a/storage/innobase/include/data0type.h
 
+++ b/storage/innobase/include/data0type.h
 
@@ -199,7 +199,7 @@ store the charset-collation number; one byte is left unused, though */
 
 #define DATA_NEW_ORDER_NULL_TYPE_BUF_SIZE      6
 
 
 
 /* Maximum multi-byte character length in bytes, plus 1 */
 
-#define DATA_MBMAX     5
 
+#define DATA_MBMAX     (MY_CS_MBMAXLEN+1)
 
 
 
 /* Pack mbminlen, mbmaxlen to mbminmaxlen. */
 
 #define DATA_MBMINMAXLEN(mbminlen, mbmaxlen)   \

BTW - still has merge conflicts in the commit above (test results)

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