| Bug #51336 | Assert in reload_acl_and_cache during RESET QUERY CACHE | ||
|---|---|---|---|
| Submitted: | 19 Feb 2010 18:03 | Modified: | 14 Mar 2010 1:25 |
| Reporter: | Matthias Leich | Email Updates: | |
| Status: | Closed | Impact on me: | |
| Category: | MySQL Server: Locking | Severity: | S3 (Non-critical) |
| Version: | 5.5.99-m3-debug-log | OS: | Any |
| Assigned to: | Jon Olav Hauglid | CPU Architecture: | Any |
| Tags: | locking, query cache, regression | ||
[22 Feb 2010 13: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/101065 3105 Jon Olav Hauglid 2010-02-22 Bug #51336 Assert in reload_acl_and_cache during RESET QUERY CACHE The triggered assert is designed to check that caches are not flushed or reset while having active transactions. It is triggered if acquired metadata locks exist that are not from LOCK TABLE or HANDLER statements. In this case it was triggered by RESET QUERY CACHE while having an active transaction that had acquired locks. This patch fixes the problem by making sure RESET statements autocommit the current transaction before executing. (This is already done for the related FLUSH statement.) Test case added to query_cache.test.
[26 Feb 2010 9:58]
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/101566 3109 Jon Olav Hauglid 2010-02-26 Bug #51336 Assert in reload_acl_and_cache during RESET QUERY CACHE Attempts to execute RESET statements within a transaction that had acquired metadata locks, led to an assertion failure on debug servers. This bug didn't cause any problems on release builds. The triggered assert is designed to check that caches are not flushed or reset while having active transactions. It is triggered if acquired metadata locks exist that are not from LOCK TABLE or HANDLER statements. In this case it was triggered by RESET QUERY CACHE while having an active transaction that had acquired locks. The reason the assertion was triggered, was that RESET statements, unlike the similar FLUSH statements, was not causing an implicit commit. This patch fixes the problem by making sure RESET statements commit the current transaction before executing. The commit causes acquired metadata locks to be released, preventing the assertion from being triggered. Incompatible change: This patch changes RESET statements so that they cause an implicit commit. Test case added to query_cache.test.
[26 Feb 2010 10:48]
Jon Olav Hauglid
Pushed to mysql-next-4284.
[6 Mar 2010 10:29]
Bugs System
Pushed into 6.0.14-alpha (revid:alik@sun.com-20100306102742-yw9zzgw9ac5r65m5) (version source revid:bar@mysql.com-20100305074327-h09o5lw290s04lcf) (merge vers: 6.0.14-alpha) (pib:16)
[6 Mar 2010 10:31]
Bugs System
Pushed into mysql-next-mr (revid:alik@sun.com-20100306102638-qna09hbjb5gm940h) (version source revid:alik@sun.com-20100304153932-9hajxhhyanqbckmu) (pib:16)
[6 Mar 2010 10:58]
Bugs System
Pushed into 5.5.3-m3 (revid:alik@sun.com-20100306103849-hha31z2enhh7jwt3) (version source revid:alik@sun.com-20100304153932-9hajxhhyanqbckmu) (merge vers: 5.5.99-m3) (pib:16)
[14 Mar 2010 1:25]
Paul DuBois
Noted in 5.5.3, 6.0.14 changelogs. For debug builds, wttempts to execute RESET statements within a transaction that had acquired metadata locks led to an assertionfailure. As a result of this bug fix, RESET statements now cause an implicit commit. Also updated implicit-commit section.
Description: The problem was found by Alfranio when running RQG tests with conf/replication-ddl_data.zz + conf/replication-ddl_sql.yy The assert happens in sql_parse.cc:6511 DBUG_ASSERT(!thd || thd->locked_tables_mode || !thd->mdl_context.has_locks() || thd->handler_tables_hash.records || thd->global_read_lock.is_acquired()); My script: ---------- --disable_warnings DROP TABLE IF EXISTS t1_does_not_exist; --enable_warnings SET AUTOCOMMIT = OFF; --error ER_NO_SUCH_TABLE SELECT * FROM t1_does_not_exist; RESET QUERY CACHE; Result on 5.5.99-m3-debug-log mysql-next-mr revno: 2964 2010-02-17 ------------------------------------ ./mysql-test-run.pl --mem --skip-ndb ml020 ... main.ml020 [ fail ] ... CURRENT_TEST: main.ml020 mysqltest: At line 8: query 'RESET QUERY CACHE' failed: 2013: Lost connection to MySQL server during query ... Version: '5.5.99-m3-debug-log' socket: ... Source distribution mysqld: sql_parse.cc:6514: bool reload_acl_and_cache(THD*, ulong, TABLE_LIST*, bool*): Assertion `!thd || thd->locked_tables_mode || !thd->mdl_context.has_locks() || thd->handler_tables_hash.records || thd->global_read_lock.is_acquired()' failed. 100219 20:54:06 - mysqld got signal 6 ; ... Thread 1 (process 17776): #0 0x00007fe57ca07ce6 in pthread_kill () from /lib64/libpthread.so.0 #1 0x0000000000b54313 in my_write_core (sig=6) at stacktrace.c:326 #2 0x00000000006b47cc in handle_segfault (sig=6) at mysqld.cc:2741 #3 <signal handler called> #4 0x00007fe57bc105c5 in raise () from /lib64/libc.so.6 #5 0x00007fe57bc11bb3 in abort () from /lib64/libc.so.6 #6 0x00007fe57bc091e9 in __assert_fail () from /lib64/libc.so.6 #7 0x00000000006c195b in reload_acl_and_cache (thd=0x13bdca8, options=65536, tables=0x0, write_to_binlog=0x416b2eaf) at sql_parse.cc:6511 #8 0x00000000006cc48e in mysql_execute_command (thd=0x13bdca8) at sql_parse.cc:3737 #9 0x00000000006ce9e1 in mysql_parse (thd=0x13bdca8, inBuf=0x1450238 "RESET QUERY CACHE", length=17, found_semicolon=0x416b3eb0) at sql_parse.cc:5581 #10 0x00000000006cf5fc in dispatch_command (command=COM_QUERY, thd=0x13bdca8, packet=0x14441a9 "RESET QUERY CACHE", packet_length=17) at sql_parse.cc:1023 #11 0x00000000006d0a70 in do_command (thd=0x13bdca8) at sql_parse.cc:709 #12 0x00000000006beea2 in do_handle_one_connection (thd_arg=0x13bdca8) at sql_connect.cc:1174 #13 0x00000000006bef67 in handle_one_connection (arg=0x13bdca8) at sql_connect.cc:1113 #14 0x0000000000b28067 in pfs_spawn_thread (arg=0x1421388) at pfs.cc:1011 #15 0x00007fe57ca03040 in start_thread () from /lib64/libpthread.so.0 #16 0x00007fe57bcb108d in clone () from /lib64/libc.so.6 #17 0x0000000000000000 in ?? () 5.1.44-debug-log (mysql-5.1 revno: 3315 2010-01-15) does not show this assertion. How to repeat: See above