Bug #84825 InnoDB: Failing assertion: *mbmaxlen < 5 in ha_innodb.cc line 1725
Submitted: 6 Feb 2017 7:24 Modified: 6 May 2017 4:12
Reporter: Roel Van de Paar Email Updates:
Status: Verified Impact on me:
None 
Category:MySQL Server: DML Severity:S6 (Debug Builds)
Version:5.6.35 OS:Any
Assigned to: CPU Architecture:Any

[6 Feb 2017 7:24] Roel Van de Paar
Description:
2017-02-06 18:00:55 18928 [Note] /sda/MS020217-mysql-5.6.35-linux-x86_64-debug/bin/mysqld: ready for connections.
Version: '5.6.35-debug'  socket: '/sda/MS020217-mysql-5.6.35-linux-x86_64-debug/socket.sock'  port: 10659  MySQL Community Server (GPL)
2017-02-06 18:01:06 7f6a324ab700  InnoDB: Assertion failure in thread 140094087018240 in file ha_innodb.cc line 1725
InnoDB: Failing assertion: *mbmaxlen < 5
InnoDB: We intentionally generate a memory trap.

Core was generated by `/sda/MS020217-mysql-5.6.35-linux-x86_64-debug/bin/mysqld --no-defaults --core -'.
Program terminated with signal 6, Aborted.
#0  0x00007f6a31eb8741 in __pthread_kill (threadid=<optimized out>, signo=6) at ../nptl/sysdeps/unix/sysv/linux/pthread_kill.c:61
61        val = INTERNAL_SYSCALL (tgkill, err, 3, THREAD_GETMEM (THREAD_SELF, pid),
(gdb) bt
#0  0x00007f6a31eb8741 in __pthread_kill (threadid=<optimized out>, signo=6) at ../nptl/sysdeps/unix/sysv/linux/pthread_kill.c:61
#1  0x0000000000a9cf79 in my_write_core (sig=6) at /git/MS-5.6.35_dbg/mysys/stacktrace.c:424
#2  0x000000000072c620 in handle_fatal_signal (sig=6) at /git/MS-5.6.35_dbg/sql/signal_handler.cc:230
#3  <signal handler called>
#4  0x00007f6a304541d7 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
#5  0x00007f6a304558c8 in __GI_abort () at abort.c:90
#6  0x0000000000b6ac21 in innobase_get_cset_width (cset=17, mbminlen=0x7f6a324a5ab8, mbmaxlen=0x7f6a324a5ab0) at /git/MS-5.6.35_dbg/storage/innobase/handler/ha_innodb.cc:1725
#7  0x0000000000d6e97e in dtype_get_mblen (mtype=13, prtype=1114366, mbminlen=0x7f6a324a5ab8, mbmaxlen=0x7f6a324a5ab0)
    at /git/MS-5.6.35_dbg/storage/innobase/include/data0type.ic:96
#8  0x0000000000d70556 in dict_mem_fill_column_struct (column=0x7f69fc0c9878, col_pos=0, mtype=13, prtype=1114366, col_len=5)
    at /git/MS-5.6.35_dbg/storage/innobase/dict/dict0mem.cc:493
#9  0x0000000000d6fc36 in dict_mem_table_add_col (table=0x7f69fc06cff8, heap=0x7f69fc0a7a00, name=0x7f69fc098461 "a", mtype=13, prtype=1114366, len=5)
    at /git/MS-5.6.35_dbg/storage/innobase/dict/dict0mem.cc:262
#10 0x0000000000b765a4 in create_table_def (trx=0x7f69fc0c7a78, form=0x7f6a324a6aa0, table_name=0x7f6a324a5e70 "test/#sql-49f0_1", temp_path=0x7f6a324a6070 "",
    remote_path=0x7f6a324a6270 "", flags=1, flags2=80) at /git/MS-5.6.35_dbg/storage/innobase/handler/ha_innodb.cc:8816
#11 0x0000000000b77ef3 in ha_innobase::create (this=0x7f69fc098810, name=0x7f6a324a87fc "./test/#sql-49f0_1", form=0x7f6a324a6aa0, create_info=0x7f6a324a8de0)
    at /git/MS-5.6.35_dbg/storage/innobase/handler/ha_innodb.cc:9732
#12 0x0000000000645ad2 in handler::ha_create (this=0x7f69fc098810, name=0x7f6a324a87fc "./test/#sql-49f0_1", form=0x7f6a324a6aa0, info=0x7f6a324a8de0)
    at /git/MS-5.6.35_dbg/sql/handler.cc:4525
#13 0x00000000006463c3 in ha_create_table (thd=0x7f6a09787000, path=0x7f6a324a87fc "./test/#sql-49f0_1", db=0x7f69fc01f690 "test", table_name=0x7f6a324a7f90 "#sql-49f0_1",
    create_info=0x7f6a324a8de0, update_create_info=false, is_temp_table=false) at /git/MS-5.6.35_dbg/sql/handler.cc:4769
#14 0x000000000084c99d in mysql_alter_table (thd=0x7f6a09787000, new_db=0x7f69fc01f690 "test", new_name=0x0, create_info=0x7f6a324a8de0, table_list=0x7f69fc01f130,
    alter_info=0x7f6a324a8d50, order_num=0, order=0x0, ignore=false) at /git/MS-5.6.35_dbg/sql/sql_table.cc:8598
#15 0x000000000098ae49 in Sql_cmd_alter_table::execute (this=0x7f69fc01f770, thd=0x7f6a09787000) at /git/MS-5.6.35_dbg/sql/sql_alter.cc:313
#16 0x00000000007dfba2 in mysql_execute_command (thd=0x7f6a09787000) at /git/MS-5.6.35_dbg/sql/sql_parse.cc:5023
#17 0x00000000007e2ff8 in mysql_parse (thd=0x7f6a09787000, rawbuf=0x7f69fc01f010 "ALTER TABLE t1 MODIFY a CHAR(1)CHARACTER SET filename", length=53, parser_state=0x7f6a324aa590)
    at /git/MS-5.6.35_dbg/sql/sql_parse.cc:6433
#18 0x00000000007d6110 in dispatch_command (command=COM_QUERY, thd=0x7f6a09787000, packet=0x7f6a0976b001 "ALTER TABLE t1 MODIFY a CHAR(1)CHARACTER SET filename",
    packet_length=53) at /git/MS-5.6.35_dbg/sql/sql_parse.cc:1372
#19 0x00000000007d50d4 in do_command (thd=0x7f6a09787000) at /git/MS-5.6.35_dbg/sql/sql_parse.cc:1039
#20 0x000000000079ca7c in do_handle_one_connection (thd_arg=0x7f6a09787000) at /git/MS-5.6.35_dbg/sql/sql_connect.cc:982
#21 0x000000000079c7ec in handle_one_connection (arg=0x7f6a09787000) at /git/MS-5.6.35_dbg/sql/sql_connect.cc:899
#22 0x0000000000ae9335 in pfs_spawn_thread (arg=0x7f6a2e7f46a0) at /git/MS-5.6.35_dbg/storage/perfschema/pfs.cc:1860
#23 0x00007f6a31eb3dc5 in start_thread (arg=0x7f6a324ab700) at pthread_create.c:308
#24 0x00007f6a3051673d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113

How to repeat:
DROP DATABASE test;CREATE DATABASE test;USE test;
CREATE TABLE t1(a NATIONAL CHAR (1)) ROW_FORMAT=DYNAMIC ENGINE=InnoDB;
ALTER TABLE t1 MODIFY a CHAR(1)CHARACTER SET filename;
[6 Feb 2017 7:24] Roel Van de Paar
See also bug 78732. This issue was never fixed in 5.6. Perhaps a backport is possible, and/or check if it is the same issue.
[6 Feb 2017 7:46] MySQL Verification Team
Hello Roel,

Thank you for the report and test case.
Observed that 5.6.35 debug build is affected.

Thanks,
Umesh
[6 Feb 2017 7:47] Roel Van de Paar
.
[6 Feb 2017 7:48] MySQL Verification Team
-- 5.7.17 - debug/release - not affected
[8 Feb 2017 13:30] Ståle Deraas
Posted by developer:
 
Roel,

As you know, you have here reported a duplicate of a bug you have previously reported (bug#78732), and this bug was fixed in 5.7.10. Is there a special prominence of this defect in 5.6, that makes you think it is especially important to fix it in 5.6, and warrant the effort of reporting, verifying, ++?
[28 Feb 2017 6:48] Roel Van de Paar
Another testcase;

DROP DATABASE test;CREATE DATABASE test;USE test;
create TABLE t1(a int key)engine=innodb row_format=redundant;
ALTER TABLE t1 MODIFY a CHAR(1)COLLATE filename;
[28 Feb 2017 6:51] Roel Van de Paar
Hi Ståle, Yes this report is just for 5.6. Would it be easy to backport this fix? Looking at the two testcases, this bug seems relatively easy to trigger. 

Could it affect data integrity in the optimized build?
[28 Feb 2017 6:54] Roel Van de Paar
Also interesting in Marco's comment in the other bug; "This leads to a corruption of a main-memory data structure inside InnoDB." - Is this the same for 5.6? If so, is this not a security issue?
[28 Feb 2017 15:25] Ståle Deraas
Posted by developer:
 
Roel,

You are using undocumented "filename" collation, so in that respect I do not really think we should spend time backporting.
[3 Mar 2017 0:48] Roel Van de Paar
Agreed in that respect Ståle. How about the other two?