Bug #54282 Crash in MDL_context::upgrade_shared_lock_to_exclusive
Submitted: 7 Jun 2010 10:08 Modified: 12 Jul 2010 17:13
Reporter: Jon Olav Hauglid Email Updates:
Status: Closed Impact on me:
None 
Category:MySQL Server: Locking Severity:S3 (Non-critical)
Version:mysql-trunk-runtime OS:Any
Assigned to: Jon Olav Hauglid CPU Architecture:Any
Triage: Triaged: D1 (Critical)

[7 Jun 2010 10:08] Jon Olav Hauglid
Description:
Trying to drop the same table twice when it's locked using LOCK TABLES,
crashes the server.

Discovered while trying to reproduce Bug#54185 using MTR.
Could turn out to be a different manifestation of the same bug.

Not repeatable with mysql-next-mr-bugfixing or mysql-trunk-bugfixing.
(trunk-runtime currently has all revisions present in trunk-bugfixing)

Stack trace:
Thread 1 (Thread 21420):
#0  __pthread_kill (threadid=<value optimized out>, signo=<value optimized out>)
    at ../nptl/sysdeps/unix/sysv/linux/pthread_kill.c:63
#1  0x0000000000a52cba in my_write_core (sig=11)
    at /export/home/x/mysql-trunk-runtime-test/mysys/stacktrace.c:326
#2  0x0000000000543519 in handle_segfault (sig=11)
    at /export/home/x/mysql-trunk-runtime-test/sql/mysqld.cc:2791
#3  <signal handler called>
#4  0x00000000006c9199 in MDL_context::upgrade_shared_lock_to_exclusive (this=0x18537d8, 
    mdl_ticket=0x0, lock_wait_timeout=31536000)
    at /export/home/x/mysql-trunk-runtime-test/sql/mdl.cc:1994
#5  0x0000000000588ea4 in wait_while_table_is_used (thd=0x1853708, table=0x191b528, 
    function=HA_EXTRA_FORCE_REOPEN) at /export/home/x/mysql-trunk-runtime-test/sql/sql_base.cc:2187
#6  0x000000000065aaa5 in mysql_rm_table_part2 (thd=0x1853708, tables=0x18e5fc8, if_exists=false, 
    drop_temporary=false, drop_view=false, dont_log_query=false)
    at /export/home/x/mysql-trunk-runtime-test/sql/sql_table.cc:2096
#7  0x000000000065a253 in mysql_rm_table (thd=0x1853708, tables=0x18e5fc8, if_exists=0 '\000', 
    drop_temporary=0 '\000') at /export/home/x/mysql-trunk-runtime-test/sql/sql_table.cc:1887
#8  0x00000000005de899 in mysql_execute_command (thd=0x1853708)
    at /export/home/x/mysql-trunk-runtime-test/sql/sql_parse.cc:3419
#9  0x00000000005e5367 in mysql_parse (thd=0x1853708, inBuf=0x18e5ef8 "DROP TABLE t1, t1", 
    length=17, parser_state=0x7fec1e83f0f0)
    at /export/home/x/mysql-trunk-runtime-test/sql/sql_parse.cc:5848

How to repeat:
CREATE TABLE t1 (a INT);
LOCK TABLE t1 WRITE;
DROP TABLE t1, t1;
[7 Jun 2010 13:15] 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/110351

3041 Jon Olav Hauglid	2010-06-07
      Bug #54282 Crash in MDL_context::upgrade_shared_lock_to_exclusive
      
      This crash happened if a table was listed twice in a DROP TABLE statement,
      and the statement was executed while in LOCK TABLES mode. Since the two
      tables were identical, they were assigned the same MDL lock ticket. When the
      ticket of the first table was set to NULL, the server crashed when trying
      to read the ticket of the second table.
      
      Listing the same table twice should give an an ER_NONUNIQ_TABLE error.
      However, this did not happen as the check for unique table names was 
      skipped due to the tables being set up to be locked using TL_IGNORE. 
      Previously the tables were locked using TL_UNLOCK which caused the
      unique check to be performed.
      
      This bug was a regression introduced by a pre-requisite patch for
      Bug#51263 "Deadlock between transactional SELECT and ALTER TABLE ...
      REBUILD PARTITION". The regression only existed in an internal team
      tree and never in any released code.
      
      This patch reverts DROP TABLE (and DROP VIEW) to the old behavior of
      taking TL_UNLOCK locks. Test case added to drop.test.
[7 Jun 2010 15:27] Dmitry Lenev
It is OK to push this patch after making adjustments to ChangeSet comment (which were discussed on IRC).
[7 Jun 2010 15:27] 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/110371

3045 Jon Olav Hauglid	2010-06-07
      Bug #54282 Crash in MDL_context::upgrade_shared_lock_to_exclusive
      
      This crash happened if a table was listed twice in a DROP TABLE statement,
      and the statement was executed while in LOCK TABLES mode. Since the two
      elements of table list were identical, they were assigned the same TABLE object. 
      During processing of the first table element, the TABLE instance was destroyed
      and the second table list element was left with a dangling reference.
      When this reference was later accessed, the server crashed.
      
      Listing the same table twice in DROP TABLES should give an ER_NONUNIQ_TABLE
      error. However, this did not happen as the check for unique table names was 
      skipped due to the lock type for table list elements being set to TL_IGNORE.
      Previously TL_UNLOCK was used and the unique check was performed.
      
      This bug was a regression introduced by a pre-requisite patch for
      Bug#51263 "Deadlock between transactional SELECT and ALTER TABLE ...
      REBUILD PARTITION". The regression only existed in an internal team
      tree and never in any released code.
      
      This patch reverts DROP TABLE (and DROP VIEW) to the old behavior of
      using TL_UNLOCK locks. Test case added to drop.test.
[7 Jun 2010 15:28] Jon Olav Hauglid
Pushed to mysql-trunk-runtime (Ver 5.5.5-m3).
[22 Jun 2010 13:08] Bugs System
Pushed into 5.5.5-m3 (revid:alik@sun.com-20100622130139-u05awgya93zvbsop) (version source revid:marko.makela@oracle.com-20100603095032-v5ptkkzt1bhz0m1d) (merge vers: 5.1.48) (pib:16)
[22 Jun 2010 13:10] Bugs System
Pushed into mysql-next-mr (revid:alik@sun.com-20100622130623-r7yhm89fz9n5t9nb) (version source revid:alik@sun.com-20100622130528-187gd949sa9b6pa6) (pib:16)
[12 Jul 2010 17:13] Paul Dubois
Noted in 5.5.5 changelog.

A crash occurred if a table that was locked with LOCK TABLES was
listed twice in a DROP TABLE statement.