MySQL Bugs: #85661: Innodb: innobase_get_cset_width assertion ut

Bug #85661	Innodb: innobase_get_cset_width assertion ut_a(cset == 0);
Submitted:	28 Mar 2017 4:02	Modified:	25 May 2018 12:52
Reporter:	Daniel Black	Email Updates:
Status:	No Feedback	Impact on me:	None
Category:	MySQL Server: InnoDB storage engine	Severity:	S3 (Non-critical)
Version:	5.7.16	OS:	Linux
Assigned to:	MySQL Verification Team	CPU Architecture:	ARM

Description:
From distro bug: https://bugs.launchpad.net/ubuntu/+source/mysql-5.7/+bug/1636572

MySQL log: https://bugs.launchpad.net/ubuntu/+source/mysql-5.7/+bug/1636572

Version: '5.7.15-0ubuntu0.16.04.1'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  (Ubuntu)
2016-10-25T16:15:48.959364Z 2 [Note] Access denied for user 'root'@'localhost' (using password: NO)
2016-10-25T16:47:04.411687Z 0 [Note] Giving 0 client threads a chance to die gracefully
2016-10-25T16:47:04.411724Z 0 [Note] Shutting down slave threads
..
2016-10-25T16:47:06.002542Z 0 [Note] /usr/sbin/mysqld: Shutdown complete

2016-10-25T16:47:45.244186Z 0 [Warning] Changed limits: max_open_files: 1024 (requested 5000)
2016-10-25T16:47:45.244224Z 0 [Warning] Changed limits: table_open_cache: 431 (requested 2000)
2016-10-25T16:47:45.374630Z 0 [Warning] TIMESTAMP with implicit DEFAULT value is deprecated. Please use --explicit_defaults_for_timestamp server option (see documentation for more details).
2016-10-25T16:47:45.375348Z 0 [Note] /usr/sbin/mysqld (mysqld 5.7.16-0ubuntu0.16.04.1) starting as process 10377 ...
..
..
016-10-25T16:47:45.384341Z 0 [Note] InnoDB: Completed initialization of buffer pool
2016-10-25T16:47:45.385450Z 0 [Note] InnoDB: If the mysqld execution user is authorized, page cleaner thread priority can be changed. See the man page of setpriority().
2016-10-25T16:47:45.396735Z 0 [Note] InnoDB: Highest supported file format is Barracuda.
2016-10-25 23:47:45 0x7f4819a82740  InnoDB: Assertion failure in thread 139947644823360 in file ha_innodb.cc line 2019
InnoDB: Failing assertion: cset == 0
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.7/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
16:47:45 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.
Attempting to collect some information that could help diagnose the problem.
As this is a crash and something is definitely wrong, the information
collection process might fail.

key_buffer_size=16777216
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 = 76382 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 0x30000
/usr/sbin/mysqld(my_print_stacktrace+0x3b)[0xe7f7db]
/usr/sbin/mysqld(handle_fatal_signal+0x489)[0x784739]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x113e0)[0x7f4818a0e3e0]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0x38)[0x7f4817dc8428]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x16a)[0x7f4817dca02a]
/usr/sbin/mysqld[0x75a5be]
/usr/sbin/mysqld(_Z30innobase_convert_from_table_idP15charset_info_stPcPKcm+0x0)[0xf017b0]
/usr/sbin/mysqld(_Z27dict_mem_fill_column_structP10dict_col_tmmmm+0xa2)[0x1145f72]
/usr/sbin/mysqld(_Z20dict_load_column_lowP12dict_table_tP16mem_block_info_tP10dict_col_tPmPPKcPKhS5_+0x3f6)[0x1139c26]
/usr/sbin/mysqld[0x113df9a]
/usr/sbin/mysqld(_Z15dict_load_tablePKcb17dict_err_ignore_t+0x757)[0x113f477]
/usr/sbin/mysqld(_Z21dict_load_table_on_idm17dict_err_ignore_t+0x672)[0x1145282]
/usr/sbin/mysqld(_Z21dict_table_open_on_idmm15dict_table_op_t+0x108)[0x112fec8]
/usr/sbin/mysqld(_Z24fts_drop_orphaned_tablesv+0x395)[0x1196a65]
/usr/sbin/mysqld(_Z29recv_recovery_rollback_activev+0x33)[0xf729c3]
/usr/sbin/mysqld(_Z34innobase_start_or_create_for_mysqlv+0x4d27)[0x1054e57]
/usr/sbin/mysqld[0xf16a19]
/usr/sbin/mysqld(_Z24ha_initialize_handlertonP13st_plugin_int+0x51)[0x7d1b91]
/usr/sbin/mysqld[0xc66585]
/usr/sbin/mysqld(_Z11plugin_initPiPPci+0x608)[0xc6dc28]
/usr/sbin/mysqld[0x77ccb4]
/usr/sbin/mysqld(_Z11mysqld_mainiPPc+0x7e4)[0x77e234]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf0)[0x7f4817db3830]
/usr/sbin/mysqld(_start+0x29)[0x774c49]
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.

How to repeat:
undertake upgrade

Hello Daniel,

Thank you for the report.
I tried to perform 5.7.15->5.7.17 upgrade with existing schema and default conf but not seeing reported issue. Could you please provide any missing details(conf file etc) which could help me reproduce this issue? I'm shortly joining the exact steps I have tried at my end while reproducing the issue.

Thanks,
Umesh

5.7.15->5.7.17 Upgrade details

Attachment: 85661.upgrade.log (application/octet-stream, text), 16.14 KiB.

Umesh, I was just transcribing this report here from the Ubuntu bug. I'm not the original author, https://launchpad.net/~fajaryanw is. The configuration files are on the launchpad bug report however they don't appear to be changed from the default. I suggest trying to follow up on the launchpad bug. Given cset==0 would equate to a character set that is somehow missing I'd be looking for changes along those lines. Maybe the user has a sql backup can show the character set usage (very optimistic I know). The 5.7.16 release notes don't indicate anything changing regarding character sets and 5.7.17 character set notes don't appear related.

This issue wasn't observed by Umesh with version 5.7.17, the question now is still observed by reporter with latest versions?. Thanks in advance.

No feedback was provided for this bug for over a month, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".