| 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: | |
| Category: | MySQL Server | Severity: | S1 (Critical) |
| Version: | 5.0.11pre | OS: | Any (All) |
| Assigned to: | Mikael Ronström | CPU Architecture: | Any |
[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.
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