Bug #12212 Crash that happens during removing of database name from cache
Submitted: 27 Jul 2005 15:58 Modified: 7 Aug 2005 2:10
Reporter: Alexey Stroganov Email Updates:
Status: Closed Impact on me:
None 
Category:MySQL Server Severity:S1 (Critical)
Version:5.0.11pre OS:Any (All)
Assigned to: Mikael Ronström CPU Architecture:Any

[27 Jul 2005 15:58] Alexey Stroganov
Description:
I am working on perl stress script that perform following main
steps:

  - read list of tests(compatible with mysqltest) from file
  - start several threads
  - each thread randomly select test from list and call mysqltest binary
    to execute it

I described you these steps for your better understanding of
circumstances of crash.

Also we have some additional test suites in mysql-test-extra-5.0 tree
and when I ran some tests from it I got crash that somehow connected
to BUG#10600(or I am wrong?).

There are now two small test cases that I used in my stress testing:

Test case 1:
------------
use test;
drop table a if exists;
create table a (b int not null);

load data infile ... (from file with 1 record)
or
insert into a values (1)

Test case 2:
------------
create database test3;
drop database test3;

And we got crash instantly after 'drop database test3' statement with folowing
backtrace:
#0  0x40128348 in strcmp () from /lib/tls/libc.so.6
#1  0x081d870e in remove_db_from_cache (db=0x8cbc8b8 "test3") at sql_base.cc:4054
#2  0x0827a251 in mysql_rm_db (thd=0x8cd3b08, db=0x8cbc8b8 "test3", if_exists=false,
    silent=false) at sql_db.cc:629
#3  0x081aa91b in mysql_execute_command (thd=0x8cd3b08) at sql_parse.cc:3580
#4  0x081afe47 in mysql_parse (thd=0x8cd3b08, inBuf=0x8cbc870 "drop database test3 #p3",
    length=23) at sql_parse.cc:5382
#5  0x081a565a in dispatch_command (command=COM_QUERY, thd=0x8cd3b08,
    packet=0x8c62ec1 "drop database test3 #p3", packet_length=24) at sql_parse.cc:1664
#6  0x081a4e62 in do_command (thd=0x8cd3b08) at sql_parse.cc:1467
#7  0x081a3f68 in handle_one_connection (arg=0x8cd3b08) at sql_parse.cc:1116
#8  0x40049aa7 in start_thread () from /lib/tls/libpthread.so.0
#9  0x4017ac2e in clone () from /lib/tls/libc.so.6

As I understand the statement 'drop database test3' lead us to invalidation
of cache and this on its turn lead to crash at this place:

(gdb) frame 1
#1  0x081d870e in remove_db_from_cache (db=0x8c6d738 "test3") at sql_base.cc:4054
4054        if (!strcmp(table->s->db, db))
(gdb) p table->s->db
$1 = 0x0
(gdb) p db
$2 = 0x8c6d738 "test3"

The question is - why table->s->db 0x0?

In my testing the problem arised only for case when number of
threads > 9

How to repeat:
Right now I am working on integration of stress test in mysql-test-run until it will be done please contact me directly and I will provide you with detail instructions
[27 Jul 2005 18:38] Mikael Ronström
When drop database is called concurrently with a drop table of any table the MySQL
Server crashes.
[5 Aug 2005 22:14] Mike Hillyer
This bug has no patch reported and no three-part version number, and cannot be documented in the changelogs. Reverting to Open status.
[6 Aug 2005 10:27] Mikael Ronström
This bug patch is found in change set
pappa:1.1909 (erroneously marked BUG #12112 should have been BUG #12212)
28 jul 2005
and will be in 5.0.11
[7 Aug 2005 2:10] Mike Hillyer
Documented in 5.0.11 changelog:

<listitem><para>
 When <literal>DROP DATABASE</literal> was called concurrently with a <literal>DROP TABLE</literal> of any table the MySQL Server crashed. (Bug #12212)
</para></listitem>
[31 Jul 2006 19:01] Bugs System
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/9847

ChangeSet@1.2259, 2006-07-31 23:02:07+04:00, dlenev@mockturtle.local +7 -0
  Fix for bug#12212/19403 "Crash that happens during removing of database name
  from cache" and #21216 "Simultaneous DROP TABLE and SHOW OPEN TABLES causes
  server to crash".
  
  Crash happened when one ran DROP DATABASE or SHOW OPEN TABLES statements
  while concurrently doing DROP TABLE (or RENAME TABLE, CREATE TABLE LIKE
  or any other command that takes name-lock) in other connection.
  
  This problem was caused by the fact that table placeholders which were
  added to table cache in order to obtain name-lock on table had
  TABLE_SHARE::db and table_name set to 0. Therefore they broke assumption
  that these members are non-0 for all tables in table cache on which some
  of our code relies.
   
  The fix sets these members for such placeholders to appropriate value making
  this assumption true again. As attempt to avoid such problems in future
  we introduce auxiliary TABLE_SHARE::set_table_cache_key() method which
  should be used when one wants to set TABLE_SHARE::table_cache_key and which
  ensures that TABLE_SHARE::table_name/db are set properly.
  
  Question for reviewer is marked by QQ mark.
[3 Aug 2006 19:52] Bugs System
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/10027

ChangeSet@1.2259, 2006-08-03 23:53:45+04:00, dlenev@mockturtle.local +7 -0
  Fix for bug#12212/19403 "Crash that happens during removing of database name
  from cache" and #21216 "Simultaneous DROP TABLE and SHOW OPEN TABLES causes
  server to crash".
  
  Crash happened when one ran DROP DATABASE or SHOW OPEN TABLES statements
  while concurrently doing DROP TABLE (or RENAME TABLE, CREATE TABLE LIKE
  or any other command that takes name-lock) in other connection.
  
  This problem was caused by the fact that table placeholders which were
  added to table cache in order to obtain name-lock on table had
  TABLE_SHARE::db and table_name set to 0. Therefore they broke assumption
  that these members are non-0 for all tables in table cache on which some
  of our code relies.
   
  The fix sets these members for such placeholders to appropriate value making
  this assumption true again. As attempt to avoid such problems in future
  we introduce auxiliary TABLE_SHARE::set_table_cache_key() methods which
  should be used when one wants to set TABLE_SHARE::table_cache_key and which
  ensure that TABLE_SHARE::table_name/db are set properly.
  
  Question for reviewer is marked by QQ mark.