| Bug #48248 | assert in MDL_ticket::upgrade_shared_lock_to_exclusive | ||
|---|---|---|---|
| Submitted: | 22 Oct 2009 21:14 | Modified: | 7 Mar 2010 1:41 |
| Reporter: | Matthias Leich | Email Updates: | |
| Status: | Closed | Impact on me: | |
| Category: | MySQL Server: Locking | Severity: | S3 (Non-critical) |
| Version: | mysql-6.0-codebase-bugfixing | OS: | Any |
| Assigned to: | Jon Olav Hauglid | CPU Architecture: | Any |
| Tags: | mdl | ||
[9 Nov 2009 11:32]
Jon Olav Hauglid
MTR test case: CREATE TABLE t1(a INT); LOCK TABLES t1 READ; REPAIR TABLE t1; MDL-related, so only present in 6.0-codebase.
[9 Nov 2009 15:12]
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/89820 3704 Jon Olav Hauglid 2009-11-09 Bug #48248 assert in MDL_ticket::upgrade_shared_lock_to_exclusive The assert would happen if REPAIR TABLE was used on a table already locked by LOCK TABLES READ. REPAIR mistakenly tried to upgrade the read-lock to exclusive, thereby triggering the assert. The cause of the problem was that REPAIR TABLE ignored errors from opening and locking tables. This is by design, as REPAIR can be used to broken tables that cannot be opened. However, repair also ignored logical errors such as the inability to exclusivly lock a table due to conflicting LOCK TABLES. This patch fixes the problem by not ignoring errors from opening and locking tables if inside LOCK TABLES mode. In LOCK TABLES we already know that the table can be opened, so that the failure to open must be a logical error. Test added to mdl_sync.test.
[10 Nov 2009 8: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/89888 3702 Jon Olav Hauglid 2009-11-10 Bug #48248 assert in MDL_ticket::upgrade_shared_lock_to_exclusive The assert would happen if REPAIR TABLE was used on a table already locked by LOCK TABLES READ. REPAIR mistakenly tried to upgrade the read-lock to exclusive, thereby triggering the assert. The cause of the problem was that REPAIR TABLE ignored errors from opening and locking tables. This is by design, as REPAIR can be used to broken tables that cannot be opened. However, repair also ignored logical errors such as the inability to exclusivly lock a table due to conflicting LOCK TABLES. This patch fixes the problem by not ignoring errors from opening and locking tables if inside LOCK TABLES mode. In LOCK TABLES we already know that the table can be opened, so that the failure to open must be a logical error. Test added to repair.test.
[10 Nov 2009 8:29]
Jon Olav Hauglid
Pushed to mysql-6.0-codebase-bugfixing (6.0.14-alpha)
[20 Nov 2009 12:57]
Bugs System
Pushed into 6.0.14-alpha (revid:kostja@sun.com-20091120124947-yi6h2jbgw0kbciwm) (version source revid:jon.hauglid@sun.com-20091110082724-mm4b2lumf6a1eg3c) (merge vers: 6.0.14-alpha) (pib:13)
[23 Nov 2009 20:00]
Paul DuBois
Noted in 6.0.14 changelog. If REPAIR TABLE was used on a table already read-locked by LOCK TABLES, the repair mistakenly tried to upgrade the read lock to an exclusive lock, triggering an assertion.
[9 Dec 2009 13:04]
Jon Olav Hauglid
Pushed to mysql-next-4284 (5.6.0-beta).
[16 Feb 2010 16:48]
Bugs System
Pushed into 6.0.14-alpha (revid:alik@sun.com-20100216101445-2ofzkh48aq2e0e8o) (version source revid:kostja@sun.com-20091211154405-c9yhiewr9o5d20rq) (merge vers: 6.0.14-alpha) (pib:16)
[16 Feb 2010 16:57]
Bugs System
Pushed into mysql-next-mr (revid:alik@sun.com-20100216101208-33qkfwdr0tep3pf2) (version source revid:kostja@sun.com-20091210084103-l4f8u62u4evoy3dc) (pib:16)
[17 Feb 2010 1:18]
Paul DuBois
Setting report to Need Merge pending push of Celosia into release tree.
[6 Mar 2010 11:02]
Bugs System
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)
[7 Mar 2010 1:41]
Paul DuBois
Noted in 5.5.3 changelog.
[13 Apr 2010 4:59]
Paul DuBois
Correction: Not present in any 5.5.x release. 5.5.3 changelog entry removed.
Description: The assert happens in mdl.cc:1027 : /* Only allow upgrades from MDL_SHARED_UPGRADABLE */ DBUG_ASSERT(m_type == MDL_SHARED_UPGRADABLE); Backtrace from mysql-6.0-codebase-bugfixing revno: 3654 2009-10-15 ------------------------------------------- Thread 1 (process 2132): #0 0x00007f6c021971f6 in pthread_kill () from /lib/libpthread.so.0 #1 0x0000000000b8f05c in my_write_core (sig=6) at stacktrace.c:309 #2 0x00000000006f6f17 in handle_segfault (sig=6) at mysqld.cc:2754 #3 <signal handler called> #4 0x00007f6c0104bfb5 in raise () from /lib/libc.so.6 #5 0x00007f6c0104dbc3 in abort () from /lib/libc.so.6 #6 0x00007f6c01044f09 in __assert_fail () from /lib/libc.so.6 #7 0x0000000000948e17 in MDL_ticket::upgrade_shared_lock_to_exclusive (this=0x3736880) at mdl.cc:1027 #8 0x000000000076411c in wait_while_table_is_used (thd=0x397b478, table=0x37b94e8, function=HA_EXTRA_PREPARE_FOR_RENAME) at sql_base.cc:2132 #9 0x00000000008948a7 in mysql_admin_table (thd=0x397b478, tables=0x398f1d8, check_opt=0x397db18, operator_name=0xd92105 "repair", lock_type=TL_WRITE, open_for_modify=true, no_warnings_for_error=false, extra_open_options=32, prepare_func=0x883f19 <prepare_for_repair>, operator_func=0x8653f2 <handler::ha_repair(THD*, st_ha_check_opt*)>, view_operator_func=0) at sql_table.cc:4688 #10 0x000000000089616b in mysql_repair_table (thd=0x397b478, tables=0x398f1d8, check_opt=0x397db18) at sql_table.cc:4995 #11 0x000000000070c75c in mysql_execute_command (thd=0x397b478) at sql_parse.cc:3034 #12 0x0000000000712b87 in mysql_parse (thd=0x397b478, inBuf=0x398f070 "REPAIR NO_WRITE_TO_BINLOG TABLE testdb_S . t1_all_1_S , testdb_S . t1_all_2_N", length=78, found_semicolon=0x7f6bf51eb900) at sql_parse.cc:5991 #13 0x00000000007137d2 in dispatch_command (command=COM_QUERY, thd=0x397b478, packet=0x38e4da9 "", packet_length=81) at sql_parse.cc:1074 #14 0x0000000000714d3d in do_command (thd=0x397b478) at sql_parse.cc:756 #15 0x0000000000701784 in handle_one_connection (arg=0x397b478) at sql_connect.cc:1164 #16 0x00007f6c021923ba in start_thread () from /lib/libpthread.so.0 #17 0x00007f6c010fefcd in clone () from /lib/libc.so.6 #18 0x0000000000000000 in ?? () The assert was found when running a RQG test with 30 threads on an derivate of the grammar WL5004_sql.yy. I will come up with a simplified testcase soon. How to repeat: See above.