MySQL Bugs: #50555: handler commands crash server in my_hash

Bug #50555	handler commands crash server in my_hash_first()
Submitted:	22 Jan 2010 19:56	Modified:	7 Mar 2010 1:11
Reporter:	Shane Bester (Platinum Quality Contributor)	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Server: General	Severity:	S1 (Critical)
Version:	5.5.99-m3-debug	OS:	Any
Assigned to:	Mikael Ronström	CPU Architecture:	Any
Tags:	regression, valgrind

Description:
I branched mysql-next-mr-bugfixing and built debug server that crashes

mysqld.exe!calc_hash()[hash.c:46]
mysqld.exe!my_hash_first()[hash.c:247]
mysqld.exe!my_hash_search()[hash.c:217]
mysqld.exe!mysql_ha_read()[sql_handler.cc:442]
mysqld.exe!mysql_execute_command()[sql_parse.cc:3953]
mysqld.exe!mysql_parse()[sql_parse.cc:5989]
mysqld.exe!dispatch_command()[sql_parse.cc:1140]
mysqld.exe!do_command()[sql_parse.cc:810]
mysqld.exe!do_handle_one_connection()[sql_connect.cc:1172]
mysqld.exe!handle_one_connection()[sql_connect.cc:1112]
mysqld.exe!pfs_spawn_thread()[pfs.cc:1011]
mysqld.exe!pthread_start()[my_winthread.c:61]
mysqld.exe!_callthreadstartex()[threadex.c:348]
mysqld.exe!_threadstartex()[threadex.c:331]
kernel32.dll!FlsSetValue()

Exact revision was this:
[sbester@box1 mysql-next-mr-bugfixing]$ bzr log |head -n 20
------------------------------------------------------------
revno: 2972
committer: Alexander Nozdrin <alik@sun.com>
branch nick: mysql-next-mr-bugfixing
timestamp: Fri 2010-01-22 11:20:13 +0300
message:
  Auto-merge from mysql-next-mr.

How to repeat:
start mysqld with --performance-schema=1
run this:

handler `performance_timers` read `idx0` first

Analysis:

The following script

drop table if exists test.t1;
create table test.t1(a int);
use test;

handler `t1` read `idx0` first;

drop table test.t1;

crashes in the same place in 5.5, but returns an error
"1109: Unknown table 't1' in HANDLER", in 5.0 and 5.1, which is expected.

In 5.0 and 5.1, when the code executes my_hash_first(),
the hash is empty (hash->records == 0), so the code returns no record,
leading later to the error printed.

Under the same conditions, my_hash_first() crashes in 5.5,
because the code has been changed in 5.5

This is a *regression* in 5.5, and is not related to the performance schema implementation.

This regression was caused by the following patch:

Revision id: mikael@mysql.com-20091009122222-aysf0ekxj4a3qg9o
Commiter: Mikael Ronstrom <mikael@mysql.com>
Branch nick: mysql-trunk-LOCK_open_first
Timestamp: Fri 2009-10-09 14:22:22 +0200
Comments:
A minor change to MySQL's hash where calculation of hash can be done separately to avoid doing it under contended mutex locks

Based on this:
- changing the category to General
- changing the bug title

Triage: this is a regression in 5.5

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/98822

2981 Mikael Ronstrom	2010-02-01
      BUG#50555, added test case

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/98823

2980 Mikael Ronstrom	2010-02-01
      BUG#50555, added check for uninitialised hash table in my_hash_first to accomodate HANDLER tables among other things

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/98923

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/98927

3063 Konstantin Osipov	2010-02-02
      A fix for Bug#50555 "handler commands crash server in my_hash_first()":
      - add assert to hash.c that the hash is never used without
      first being initialized.
      - add results for the test case for Bug#50555
      - add a check to set_var.cc, intern_find_sys_var() 
      that the sys var hash is initalized.
      The order of initalization of system variables and plugins
      is intermixed, and in plugin_shutdown() we may call cleanup_variables()
      without having first called init_set_var().
     @ mysys/hash.c
        Assert that the hash is initialized when it's used.
     @ sql/set_var.cc
        Check that the hash is initalized before using it (Bug#50555)
     @ sql/sql_handler.cc
        Check that the hash is initalized before using it.

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/98954

A fix for this bug was queued into next-4284.

Pushed into 6.0.14-alpha (revid:alik@sun.com-20100216101445-2ofzkh48aq2e0e8o) (version source revid:kostja@sun.com-20100210211106-nq8ztcq2z9o4csit) (merge vers: 6.0.14-alpha) (pib:16)

Pushed into mysql-next-mr (revid:alik@sun.com-20100216101208-33qkfwdr0tep3pf2) (version source revid:kostja@sun.com-20100202135815-56j3kism4x4zp2q0) (pib:16)

Noted in 6.0.14 changelog.

An uninitialized hash table caused a crash when accessed.

Setting report to Need Merge pending push of Celosia to release tree.

Pushed into 5.5.3-m3 (revid:alik@sun.com-20100306103849-hha31z2enhh7jwt3) (version source revid:vvaintroub@mysql.com-20100216221947-luyhph0txl2c5tc8) (merge vers: 5.5.99-m3) (pib:16)

Noted in 5.5.3 changelog.

Correction: No changelog entry needed.