Bug #70431 5.6 CRASHES WHEN READING ANCIENT SYSTEM TABLES
Submitted: 26 Sep 2013 8:05 Modified: 15 Jul 2015 7:11
Reporter: Ruly Kurniawan Email Updates:
Status: Verified Impact on me:
None 
Category:MySQL Server: Security: Privileges Severity:S1 (Critical)
Version:5.6.13 OS:Any (CentOS)
Assigned to: CPU Architecture:Any

[26 Sep 2013 8:05] Ruly Kurniawan
Description:
Hi,

I just updated my MySQL Server to version 5.6.13. After I updated, everything work fine, until I restored the database from a dump file. I got this in the log file:

key_buffer_size=33554432
read_buffer_size=1048576
max_used_connections=0
max_threads=20
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 = 299279 K  bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

Thread pointer: 0x343a470
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 = 7fff8d158bb8 thread_stack 0x40000
/usr/sbin/mysqld(my_print_stacktrace+0x35)[0x8c90d5]
/usr/sbin/mysqld(handle_fatal_signal+0x4a4)[0x65cee4]
/lib64/libpthread.so.0[0x3129a0f500]
/usr/sbin/mysqld(_Z9get_fieldP11st_mem_rootP5Field+0x5a)[0x76452a]
/usr/sbin/mysqld(_Z10acl_reloadP3THD+0xb32)[0x677952]
/usr/sbin/mysqld(_Z8acl_initb+0x120)[0x6790b0]
/usr/sbin/mysqld(_Z11mysqld_mainiPPc+0x996)[0x59bd36]
/lib64/libc.so.6(__libc_start_main+0xfd)[0x312921ecdd]
/usr/sbin/mysqld[0x58e191]

Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
Query (0): is an invalid pointer
Connection ID (thread ID): 0
Status: NOT_KILLED

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.
130925 18:48:38 mysqld_safe Number of processes running now: 0
130925 18:48:38 mysqld_safe mysqld restarted
130925 18:48:38 mysqld_safe mysqld from pid file /var/lib/mysql/mysql.pid ended
130926 10:02:00 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
2013-09-26 10:02:01 0 [Warning] TIMESTAMP with implicit DEFAULT value is deprecated. Please use --explicit_defaults_for_timestamp server option (see documentation for more details).
2013-09-26 10:02:01 2730 [Note] Plugin 'FEDERATED' is disabled.
2013-09-26 10:02:01 2730 [Note] InnoDB: The InnoDB memory heap is disabled
2013-09-26 10:02:01 2730 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2013-09-26 10:02:01 2730 [Note] InnoDB: Compressed tables use zlib 1.2.3
2013-09-26 10:02:01 2730 [Note] InnoDB: Using Linux native AIO
2013-09-26 10:02:01 2730 [Note] InnoDB: Using CPU crc32 instructions
2013-09-26 10:02:01 2730 [Note] InnoDB: Initializing buffer pool, size = 1.0G
2013-09-26 10:02:01 2730 [Note] InnoDB: Completed initialization of buffer pool
2013-09-26 10:02:01 2730 [Note] InnoDB: Highest supported file format is Barracuda.
2013-09-26 10:02:01 2730 [Note] InnoDB: 128 rollback segment(s) are active.
2013-09-26 10:02:01 2730 [Note] InnoDB: Waiting for purge to start
2013-09-26 10:02:02 2730 [Note] InnoDB: 5.6.13 started; log sequence number 6963782201
2013-09-26 10:02:02 2730 [Note] Server hostname (bind-address): '0.0.0.0'; port: 3306
2013-09-26 10:02:02 2730 [Note]   - '0.0.0.0' resolves to '0.0.0.0';
2013-09-26 10:02:02 2730 [Note] Server socket created on IP: '0.0.0.0'.
03:02:02 UTC - mysqld got signal 11 ;
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.

The content of the config file:
[mysqld]
basedir=/usr
bind-address    = 0.0.0.0
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
interactive_timeout=380
wait_timeout=380
port=3306
user=mysql
skip-external-locking
skip-name-resolve
skip-innodb_doublewrite
#skip-grant-tables
long_query_time=5

back_log = 75
log_bin_trust_function_creators = 1
lower_case_table_names = 1
max_sp_recursion_depth = 10
lower_case_table_names = 1
key_buffer_size=32M
sort_buffer_size=12M
join_buffer_size=16M
query_cache_limit=4M
query_cache_size=128M
query-cache-type=1
#max_heap_table_size=2048M
#tmp_table_size=2048M

max_connections=20
max_connect_errors=10
max_allowed_packet=1M
binlog_cache_size=1M
thread_concurrency=4
thread_stack=256K
ft_min_word_len=4
read_buffer_size=1M
read_rnd_buffer_size=4M
server-id=1
low_priority_updates=1
concurrent_insert=2
innodb_status_file=0
innodb_data_home_dir=/var/lib/mysql/innodb
innodb_data_file_path=ibdata1:200M:autoextend
innodb_log_group_home_dir=/var/lib/mysql/innodb
innodb_buffer_pool_size=1024M
innodb_log_file_size=500M
innodb_log_files_in_group=2
innodb_log_buffer_size=8M
innodb_flush_log_at_trx_commit=1
innodb_lock_wait_timeout=120
innodb_open_files=30480
innodb_thread_concurrency=8
innodb_flush_method = O_DSYNC
#innodb_force_recovery=3
transaction_isolation=REPEATABLE-READ

# Disabling symbolic-links is recommended to prevent assorted security risks
symbolic-links=0
lower_case_table_names=1
pid-file=/var/lib/mysql/mysql.pid
sql_mode=NO_ENGINE_SUBSTITUTION,STRICT_TRANS_TABLES

[mysqld_safe]
log-error=/var/lib/mysql/mysqld.log
pid-file=/var/lib/mysql/mysql.pid
open-files-limit = 30480

How to repeat:
-
[26 Sep 2013 9:05] MySQL Verification Team
Are you restoring an older version's `mysql` database over the one that comes with 5.6.13?

Which version?  You can start the server by adding skip-grant-tables to my.cnf and check what the structure of `mysql`.`user` table looks like.
[26 Sep 2013 9:07] MySQL Verification Team
internally, I have:
Bug 16343542 - 5.6 CRASHES WHEN READING ANCIENT SYSTEM TABLES
[26 Sep 2013 9:21] Ruly Kurniawan
Are you restoring an older version's `mysql` database over the one that
comes with 5.6.13?

Which version?  You can start the server by adding skip-grant-tables to
my.cnf and check what the structure of `mysql`.`user` table looks like.

Yes, my old MySQL server is 5.0.xx (I forget the revision number).
I already un-comment the skip-grant-tables in the my.cnf and it's working now. I can start my mysqld. Can I know what cause this?
[26 Sep 2013 9:42] MySQL Verification Team
You're essentially wiping out the 5.6 system tables with invalid 5.0 tables.
That is not a good thing to do.

mysql_upgrade might fix it, but mysql_upgrade is only meant to deal with system tables from 5.5->5.6.

A segfault isn't expected, that is what my internal bug report is about.
If you want to upgrade from 5.0 to 5.6 via dump/reload, I recommend you skip the `mysql` database and recreate your privileges/users via GRANT statements in 5.6.
[26 Sep 2013 19:49] MySQL Verification Team
5.6.15 crashes on startup with 5.0.96 mysql.user table.

mysqld-debug.exe!Field::val_str()[field.h:634]
mysqld-debug.exe!get_field()[table.cc:3118]
mysqld-debug.exe!acl_load()[sql_acl.cc:1150]
mysqld-debug.exe!acl_reload()[sql_acl.cc:1639]
mysqld-debug.exe!acl_init()[sql_acl.cc:1004]
mysqld-debug.exe!win_main()[mysqld.cc:5530]
mysqld-debug.exe!mysql_service()[mysqld.cc:5717]
mysqld-debug.exe!mysqld_main()[mysqld.cc:5910]
mysqld-debug.exe!main()[main.cc:26]
mysqld-debug.exe!__tmainCRTStartup()[crt0.c:278]
mysqld-debug.exe!mainCRTStartup()[crt0.c:189]

Marking this as a duplicate of my internal bug.
To repeat:
----
start 5.6.
drop table mysql.user;
create table mysql.user .....  (5.0.96 structure).
insert into mysql.user set user='root',host='%',password='';
restart 5.6.
----

The above is considered unsupported, so let us not be surprised if this bug gets rejected or turned into a feature request.
[26 Sep 2013 19:53] MySQL Verification Team
Our documentation says
http://dev.mysql.com/doc/refman/5.6/en/upgrading.html

"As a general rule, to upgrade from one release series to another, go to the
next series rather than skipping a series. To upgrade from a release series
previous to MySQL 5.5, upgrade to each successive release series in turn
until you have reached MySQL 5.5, and then proceed with the upgrade to MySQL
5.6.".
[27 Sep 2013 1:25] Ruly Kurniawan
Noted. Thank you for the explanation.
[15 Jul 2015 7:07] MySQL Verification Team
Bug #77516 marked as duplicate of this