Bug #68385 CREATE USER ... with IDENTIFIED BY clause crashes mysqld
Submitted: 14 Feb 2013 21:09 Modified: 1 Apr 2013 15:58
Reporter: Roland Bouman Email Updates:
Status: Closed Impact on me:
None 
Category:MySQL Server Severity:S1 (Critical)
Version:5.6 OS:Linux (mysql-5.6.10-linux-glibc2.5-x86_64)
Assigned to: Matthew Lord CPU Architecture:Any

[14 Feb 2013 21:09] Roland Bouman
Description:
Any statement of the form

CREATE USER x IDENTIFIED BY 'x'

crashes mysqld.

How to repeat:
Clean install out of generic linux tar.gz package. Ran install script. Then loaded data from previously created mysql dump. 
Then run any statement like:

CREATE USER x IDENTIFIED BY 'x'

Stacktrace in error log:

20:58:30 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.

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

Thread pointer: 0x28b1d80
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 = 7f569c6efe20 thread_stack 0x40000
bin/mysqld(my_print_stacktrace+0x35)[0x8f0d25]
bin/mysqld(handle_fatal_signal+0x3e8)[0x66b138]
/lib/x86_64-linux-gnu/libpthread.so.0(+0xfcb0)[0x7f56a00fdcb0]
bin/mysqld[0x68fbdf]
bin/mysqld(_Z17mysql_create_userP3THDR4ListI11st_lex_userE+0x2f7)[0x693267]
bin/mysqld(_Z21mysql_execute_commandP3THD+0x3c05)[0x6e89e5]
bin/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x318)[0x6eba58]
bin/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x827)[0x6ec377]
bin/mysqld(_Z10do_commandP3THD+0xd7)[0x6ed617]
bin/mysqld(_Z24do_handle_one_connectionP3THD+0x116)[0x6b7e06]
bin/mysqld(handle_one_connection+0x45)[0x6b7ee5]
bin/mysqld(pfs_spawn_thread+0x13b)[0xab465b]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x7e9a)[0x7f56a00f5e9a]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7f569edc9cbd]

Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
Query (7f5644004f00): create user piet identified by 'piet'
Connection ID (thread ID): 1
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.

Suggested fix:
Don't crash.
[14 Feb 2013 21:12] Roland Bouman
I'm getting same problem with a SET PASSWORD command. (either with or without FOR clause). I can tell it must be after finding the row in the user table, because it will give an expected error if the user doesn't yet exist. 

21:08:48 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.

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

Thread pointer: 0x3a7dd80
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 = 7f5a3f3d6e20 thread_stack 0x40000
bin/mysqld(my_print_stacktrace+0x35)[0x8f0d25]
bin/mysqld(handle_fatal_signal+0x3e8)[0x66b138]
/lib/x86_64-linux-gnu/libpthread.so.0(+0xfcb0)[0x7f5a7f793cb0]
bin/mysqld[0x67eb12]
bin/mysqld(_Z15change_passwordP3THDPKcS2_Pc+0x36a)[0x695a6a]
bin/mysqld(_ZN16set_var_password6updateEP3THD+0x1e)[0x66960e]
bin/mysqld(_Z17sql_set_variablesP3THDP4ListI12set_var_baseE+0x89)[0x669fc9]
bin/mysqld(_Z21mysql_execute_commandP3THD+0x241e)[0x6e71fe]
bin/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x318)[0x6eba58]
bin/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x827)[0x6ec377]
bin/mysqld(_Z10do_commandP3THD+0xd7)[0x6ed617]
bin/mysqld(_Z24do_handle_one_connectionP3THD+0x116)[0x6b7e06]
bin/mysqld(handle_one_connection+0x45)[0x6b7ee5]
bin/mysqld(pfs_spawn_thread+0x13b)[0xab465b]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x7e9a)[0x7f5a7f78be9a]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7f5a7e45fcbd]

Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
Query (7f5a28004f00): set password for sakila = PASSWORD('sakila')
Connection ID (thread ID): 1
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.
[14 Feb 2013 21:42] Matthew Lord
Hi Roland!

I'm unable to repeat this:

mysql> select version();
+-------------------------------------------+
| version()                                 |
+-------------------------------------------+
| 5.6.10-enterprise-commercial-advanced-log |
+-------------------------------------------+
1 row in set (0.04 sec)

mysql> create user sakila@localhost;
Query OK, 0 rows affected (0.08 sec)

mysql> set password for sakila@localhost = PASSWORD('sa90k!ilSa');
Query OK, 0 rows affected (0.01 sec)

mysql> create user sakila2@localhost identified by 'sa90k!ilSa';
Query OK, 0 rows affected (0.00 sec)

Here's the config that I'm currently using:
[mysqld56]
user=mysql
server_id=5
skip-slave-start
mysqld=/usr/local/mysql56/bin/mysqld
basedir=/usr/local/mysql56
datadir=/var/lib/mysql/mysql5.6
log_error=/var/lib/mysql/mysql5.6/bootyjr.err
innodb_data_home_dir=/var/lib/innodb/5.6
innodb_log_group_home_dir=/var/lib/innodb/5.6
socket=/tmp/mysql56.sock
port=3356
lc-messages-dir = /usr/local/mysql56/share
open_files_limit = 20000

max_connections = 2500
thread_cache_size=64

plugin-load=thread_pool.so;authentication_pam.so;validate_password.so
thread_pool_size = 36

validate-password = FORCE_PLUS_PERMANENT
validate_password_dictionary_file = "/usr/share/hunspell/en_US.dic"
# 2 == STRONG
validate_password_policy = 2

query_cache_type = 0
query_cache_size = 0

# setup P_S
performance_schema
performance_schema_instrument='%=on'

innodb_buffer_pool_size = 2G
innodb_buffer_pool_instances=2
innodb_max_dirty_pages_pct=75
innodb_adaptive_max_sleep_delay=1000000
innodb_data_home_dir=/var/lib/innodb/5.6
innodb_log_group_home_dir=/var/lib/innodb/5.6
innodb_log_file_size=2000M
innodb_log_buffer_size=32M

innodb_flush_method=O_DSYNC
innodb_flush_log_at_trx_commit=2
innodb_flushing_avg_loops = 100
innodb_flush_log_at_timeout = 10
innodb_max_dirty_pages_pct_lwm = 50
innodb_purge_threads=4
innodb_purge_batch_size=300
innodb_max_purge_lag=5000000

innodb_io_capacity=400
innodb_io_capacity_max=2400
innodb_read_io_threads=12
innodb_write_io_threads=10

innodb_file_per_table=1
innodb_file_format=barracuda
innodb_autoinc_lock_mode=2
innodb_open_files = 512
#innodb_strict_mode=1
innodb_support_xa=0
innodb_locks_unsafe_for_binlog
innodb_table_locks=0
innodb_thread_sleep_delay=0
innodb_use_native_aio=1
innodb_spin_wait_delay = 24

#innodb_analyze_is_persistent=1
innodb_stats_persistent=1
innodb_stats_on_metadata=0
innodb_stats_persistent_sample_pages=40
innodb_stats_transient_sample_pages=16
innodb_buffer_pool_dump_at_shutdown=1
innodb_change_buffer_max_size=40
innodb_checksum_algorithm=crc32
innodb_concurrency_tickets=2000

# Good for SSDs
innodb_flush_neighbors=0
innodb_page_size=4k

innodb_print_all_deadlocks=1
innodb_lru_scan_depth=512

innodb_change_buffering = ALL
innodb_sync_array_size = 1024
innodb_undo_logs = 4

binlog_format = ROW
binlog-checksum = CRC32
# binlog_direct_non_transactional_updates = ON
binlog_row_image = minimal
binlog_rows_query_log_events = 1

gtid-mode = ON
enforce-gtid-consistency=true
log-bin
log-slave-updates
master_info_repository = TABLE
relay_log_info_repository = TABLE
slave-parallel-workers = 5
master-verify-checksum = 1
slave-sql-verify-checksum = 1

table_open_cache = 8000
table_open_cache_instances = 16

# END CONFIG

Can you show me the config file that you're using?

Have you yet generated a core file that shows where the crash occurred?
[14 Feb 2013 21:43] Roland Bouman
my.cnf at Matts request

Attachment: my.cnf (application/octet-stream, text), 4.75 KiB.

[14 Feb 2013 21:51] Roland Bouman
Hi Matt, btw here's my version (already in the report but good to confirm)

mysql> select version();
+-----------+
| version() |
+-----------+
| 5.6.10    |
+-----------+

I enabled core dumps by adding a

core-file

line to my.cnf. 
I now have a 1G core file. What do you want me to do with it?
[14 Feb 2013 22:01] Matthew Lord
Hi Roland,

OK, you have a pretty minimal config. I don't see any settings clearly related. 

I downloaded 5.6.10 community and started it with a fresh datadir and no defaults:

1) ./mysql-5.6.10-linux-glibc2.5-x86_64/scripts/mysql_install_db --no-defaults --datadir=./mysql-5.6.10-linux-glibc2.5-x86_64/data --basedir=./mysql-5.6.10-linux-glibc2.5-x86_64 

2) chown -R mysql:mysql ./mysql-5.6.10-linux-glibc2.5-x86_64/data/

3) ./mysql-5.6.10-linux-glibc2.5-x86_64/bin/mysqld --no-defaults --basedir=./mysql-5.6.10-linux-glibc2.5-x86_64 --datadir=./mysql-5.6.10-linux-glibc2.5-x86_64/data --user=mysql &

4) ./mysql-5.6.10-linux-glibc2.5-x86_64/bin/mysql --socket=/tmp/mysql.sock

mysql> show global variables like "%version%";
+-------------------------+------------------------------+
| Variable_name           | Value                        |
+-------------------------+------------------------------+
| innodb_version          | 1.2.10                       |
| protocol_version        | 10                           |
| slave_type_conversions  |                              |
| version                 | 5.6.10                       |
| version_comment         | MySQL Community Server (GPL) |
| version_compile_machine | x86_64                       |
| version_compile_os      | linux-glibc2.5               |
+-------------------------+------------------------------+
7 rows in set (0.00 sec)

mysql> create user sakila@localhost identified by 'sakila';
Query OK, 0 rows affected (0.00 sec)

mysql> status;
--------------
./mysql-5.6.10-linux-glibc2.5-x86_64/bin/mysql  Ver 14.14 Distrib 5.6.10, for linux-glibc2.5 (x86_64) using  EditLine wrapper

Connection id:		1
Current database:	
Current user:		root@localhost
SSL:			Not in use
Current pager:		stdout
Using outfile:		''
Using delimiter:	;
Server version:		5.6.10 MySQL Community Server (GPL)
Protocol version:	10
Connection:		Localhost via UNIX socket
Server characterset:	latin1
Db     characterset:	latin1
Client characterset:	utf8
Conn.  characterset:	utf8
UNIX socket:		/tmp/mysql.sock
Uptime:			2 min 23 sec

Threads: 1  Questions: 7  Slow queries: 0  Opens: 67  Flush tables: 1  Open tables: 60  Queries per second avg: 0.048
--------------

mysql> show grants for sakila@localhost;
+---------------------------------------------------------------------------------------------------------------+
| Grants for sakila@localhost                                                                                   |
+---------------------------------------------------------------------------------------------------------------+
| GRANT USAGE ON *.* TO 'sakila'@'localhost' IDENTIFIED BY PASSWORD '*FDAF706717E70DB8DDAD0C5214B13770E1A80B0E' |
+---------------------------------------------------------------------------------------------------------------+
1 row in set (0.00 sec)
[14 Feb 2013 22:04] Matthew Lord
This is becoming more of a support request than a bug report.

You can examine the core file to get some basics this way:
  gdb <path to mysqld> <path to core file>

  gdb) set print pretty on
  gdb) set print object on
  gdb) set pagination off
  gdb) bt full 
  gdb) thread apply all bt

Those are just the most basic commands to start with.

Please let me know if you feel that I'm missing anything in my attempts to repeat the bug. I am marking this as can't repeat for now, because I cannot repeat it.
[14 Feb 2013 22:06] Matthew Lord
Hi Roland,

Are you able to repeat the crash using a freshly created datadir?

I suspect that perhaps we have some old and un-upgraded system tables in use? That would be my first guess.

Best Regards,

Matt
[14 Feb 2013 22:06] Roland Bouman
Ok fair enough. I'll try and see what I can find with gdb.
[14 Feb 2013 22:13] Matthew Lord
Hi Roland,

OK, please let me know what you find.

Once we can at least get a good stack trace, then we can go from there.

Best Regards,

Matt
[14 Feb 2013 22:43] Roland Bouman
Investigated a bit more. It seems I can reproduce it using this path:

#1 start with empty data dir.
#2 run the mysql_install_db script (verified it completes normally)

at this point, everything works fine and the statement doesn't crash

#3 reload a dump of the mysql database. (attached)

at this point, the crashing starts after issuing statements mentioned above.
[14 Feb 2013 22:45] Roland Bouman
Dump of the mysql database. Load this after fresh install to reproduce the crash.

Attachment: mysql.dump.sql.zip (application/zip, text), 209.28 KiB.

[14 Feb 2013 23:05] Matthew Lord
Hi Roland,

Thank you for the bug report!  I was able to verify it this way:

1) ./mysql-5.6.10-linux-glibc2.5-x86_64/scripts/mysql_install_db --no-defaults --datadir=./mysql-5.6.10-linux-glibc2.5-x86_64/data --basedir=./mysql-5.6.10-linux-glibc2.5-x86_64 

 2) ./mysql-5.6.10-linux-glibc2.5-x86_64/bin/mysqld --no-defaults --basedir=./mysql-5.6.10-linux-glibc2.5-x86_64 --datadir=./mysql-5.6.10-linux-glibc2.5-x86_64/data --user=root &

3) ./mysql-5.6.10-linux-glibc2.5-x86_64/bin/mysql --socket=/tmp/mysql.sock

4) USE `mysql`;

DROP TABLE IF EXISTS `user`;
/*!40101 SET @saved_cs_client     = @@character_set_client */;
/*!40101 SET character_set_client = utf8 */;
CREATE TABLE `user` (
  `Host` char(60) COLLATE utf8_bin NOT NULL DEFAULT '',
  `User` char(16) COLLATE utf8_bin NOT NULL DEFAULT '',
  `Password` char(41) CHARACTER SET latin1 COLLATE latin1_bin NOT NULL DEFAULT '',
  `Select_priv` enum('N','Y') CHARACTER SET utf8 NOT NULL DEFAULT 'N',
  `Insert_priv` enum('N','Y') CHARACTER SET utf8 NOT NULL DEFAULT 'N',
  `Update_priv` enum('N','Y') CHARACTER SET utf8 NOT NULL DEFAULT 'N',
  `Delete_priv` enum('N','Y') CHARACTER SET utf8 NOT NULL DEFAULT 'N',
  `Create_priv` enum('N','Y') CHARACTER SET utf8 NOT NULL DEFAULT 'N',
  `Drop_priv` enum('N','Y') CHARACTER SET utf8 NOT NULL DEFAULT 'N',
  `Reload_priv` enum('N','Y') CHARACTER SET utf8 NOT NULL DEFAULT 'N',
  `Shutdown_priv` enum('N','Y') CHARACTER SET utf8 NOT NULL DEFAULT 'N',
  `Process_priv` enum('N','Y') CHARACTER SET utf8 NOT NULL DEFAULT 'N',
  `File_priv` enum('N','Y') CHARACTER SET utf8 NOT NULL DEFAULT 'N',
  `Grant_priv` enum('N','Y') CHARACTER SET utf8 NOT NULL DEFAULT 'N',
  `References_priv` enum('N','Y') CHARACTER SET utf8 NOT NULL DEFAULT 'N',
  `Index_priv` enum('N','Y') CHARACTER SET utf8 NOT NULL DEFAULT 'N',
  `Alter_priv` enum('N','Y') CHARACTER SET utf8 NOT NULL DEFAULT 'N',
  `Show_db_priv` enum('N','Y') CHARACTER SET utf8 NOT NULL DEFAULT 'N',
  `Super_priv` enum('N','Y') CHARACTER SET utf8 NOT NULL DEFAULT 'N',
  `Create_tmp_table_priv` enum('N','Y') CHARACTER SET utf8 NOT NULL DEFAULT 'N',
  `Lock_tables_priv` enum('N','Y') CHARACTER SET utf8 NOT NULL DEFAULT 'N',
  `Execute_priv` enum('N','Y') CHARACTER SET utf8 NOT NULL DEFAULT 'N',
  `Repl_slave_priv` enum('N','Y') CHARACTER SET utf8 NOT NULL DEFAULT 'N',
  `Repl_client_priv` enum('N','Y') CHARACTER SET utf8 NOT NULL DEFAULT 'N',
  `Create_view_priv` enum('N','Y') CHARACTER SET utf8 NOT NULL DEFAULT 'N',
  `Show_view_priv` enum('N','Y') CHARACTER SET utf8 NOT NULL DEFAULT 'N',
  `Create_routine_priv` enum('N','Y') CHARACTER SET utf8 NOT NULL DEFAULT 'N',
  `Alter_routine_priv` enum('N','Y') CHARACTER SET utf8 NOT NULL DEFAULT 'N',
  `Create_user_priv` enum('N','Y') CHARACTER SET utf8 NOT NULL DEFAULT 'N',
  `Event_priv` enum('N','Y') CHARACTER SET utf8 NOT NULL DEFAULT 'N',
  `Trigger_priv` enum('N','Y') CHARACTER SET utf8 NOT NULL DEFAULT 'N',
  `Create_tablespace_priv` enum('N','Y') CHARACTER SET utf8 NOT NULL DEFAULT 'N',
  `ssl_type` enum('','ANY','X509','SPECIFIED') CHARACTER SET utf8 NOT NULL DEFAULT '',
  `ssl_cipher` blob NOT NULL,
  `x509_issuer` blob NOT NULL,
  `x509_subject` blob NOT NULL,
  `max_questions` int(11) unsigned NOT NULL DEFAULT '0',
  `max_updates` int(11) unsigned NOT NULL DEFAULT '0',
  `max_connections` int(11) unsigned NOT NULL DEFAULT '0',
  `max_user_connections` int(11) unsigned NOT NULL DEFAULT '0',
  `plugin` char(64) COLLATE utf8_bin DEFAULT '',
  `authentication_string` text COLLATE utf8_bin,
  PRIMARY KEY (`Host`,`User`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_bin COMMENT='Users and global privileges';
/*!40101 SET character_set_client = @saved_cs_client */;

create user sakila@localhost identified by 'sakila';

I then get the crash:
mysql> create user sakila@localhost identified by 'sakila';
23:00:59 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.

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

Thread pointer: 0x2775600
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 = 7f4d09135e20 thread_stack 0x40000
./mysql-5.6.10-linux-glibc2.5-x86_64/bin/mysqld(my_print_stacktrace+0x35)[0x8f0d25]
./mysql-5.6.10-linux-glibc2.5-x86_64/bin/mysqld(handle_fatal_signal+0x3e8)[0x66b138]
/lib/x86_64-linux-gnu/libpthread.so.0(+0xfcb0)[0x7f4d20064cb0]
./mysql-5.6.10-linux-glibc2.5-x86_64/bin/mysqld[0x68fbdf]
./mysql-5.6.10-linux-glibc2.5-x86_64/bin/mysqld(_Z17mysql_create_userP3THDR4ListI11st_lex_userE+0x2f7)[0x693267]
./mysql-5.6.10-linux-glibc2.5-x86_64/bin/mysqld(_Z21mysql_execute_commandP3THD+0x3c05)[0x6e89e5]
./mysql-5.6.10-linux-glibc2.5-x86_64/bin/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x318)[0x6eba58]
./mysql-5.6.10-linux-glibc2.5-x86_64/bin/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x827)[0x6ec377]
./mysql-5.6.10-linux-glibc2.5-x86_64/bin/mysqld(_Z10do_commandP3THD+0xd7)[0x6ed617]
./mysql-5.6.10-linux-glibc2.5-x86_64/bin/mysqld(_Z24do_handle_one_connectionP3THD+0x116)[0x6b7e06]
./mysql-5.6.10-linux-glibc2.5-x86_64/bin/mysqld(handle_one_connection+0x45)[0x6b7ee5]
./mysql-5.6.10-linux-glibc2.5-x86_64/bin/mysqld(pfs_spawn_thread+0x13b)[0xab465b]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x7e9a)[0x7f4d2005ce9a]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7f4d1ed2ccbd]

Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
Query (7f4cfc004ec0): create user sakila@localhost identified by 'sakila'
Connection ID (thread ID): 1
Status: NOT_KILLED

I will now copy this over to the development team so that they can begin working on the fix. The issue seems to be that we're not properly handling a mysql.user table taken from 5.5 or earlier.

Thanks again!

Matt
[14 Feb 2013 23:09] Roland Bouman
Matt, no problem, glad to.

I can also report that my current workaround for the password is to simply do:

UPDATE mysql.user 
SET password = PASSWORD('sakila')
WHERE user = 'sakila';

..and so on.

This seems to restore ability to login as respective user, and also gives access to their databases. But a SHOW GRANTS statement will still fail to print out actual privileges. 

Should I find more detailed info on that issue, I will file a separate request.

Thanks again for your effort - I really appreciate how fast you moved in to pick this up.

Cheers, Roland.
[14 Feb 2013 23:14] Matthew Lord
OK, I've now copied it over.

The suggested fix is:
We should check the existing structure of the mysql.user table and produce an
error when it has not yet been upgraded for 5.6 use.
[15 Feb 2013 0:04] Roland Bouman
Hi Matt, Thanks!

FWIW, I have some doubt regarding the fix. 
I mean, AFAIK the initial run of mysql_install_db should have created the table. Since the dump uses CREATE TABLE IF NOT EXISTS statements, it seems that cannot be responsible for changing the structure of any table at all - only for loading data into them.
Anyway - not my job to dictate the direction of the solution but it seems to me it's the data, not the structure that was culprit.
[15 Feb 2013 6:01] MySQL Verification Team
if you reload the mysql database after running mysql_install_db, you need to run mysql_upgrade....
[15 Feb 2013 6:04] MySQL Verification Team
you are lacking the password_expired column in the user table!
[21 Feb 2013 13:32] MySQL Verification Team
bug #68409 is a duplicate of this.
[5 Mar 2013 17:34] MySQL Verification Team
bug #68576 is a duplicate
[6 Mar 2013 8:35] Venu Anuganti
You should def fix this bug, check the patch in Bug #68576; when I tested in debugger it worked fine for 5.5 & 5.6
[1 Apr 2013 15:58] Paul DuBois
Noted in 5.6.12, 5.7.2 changelogs.

In a MySQL server newer than MySQL 5.5 using a nonupgraded mysql.proc
table (for which mysql_upgrade had not been run), statements to set
passwords caused a server exit due to a faulty check for the
password_expired column.
[26 Apr 2013 17:40] Paul DuBois
Corrected changelog entry:

In a MySQL server newer than MySQL 5.5 using a nonupgraded mysql.user
table (for which mysql_upgrade had not been run), statements to set 
passwords caused a server exit due to a faulty check for the
password_expired column.
[11 Nov 2013 19:20] Ben Ritchie
Hey guys i used mysql_upgrade and it fixes my crashing issue - thanks for sharing the workaround