| Bug #51376 | Assert `! is_set()' failed in Diagnostics_area::set_ok_status on DROP FUNCTION | ||
|---|---|---|---|
| Submitted: | 22 Feb 2010 9:00 | Modified: | 7 Mar 2010 0:55 |
| Reporter: | Philip Stoev | Email Updates: | |
| Status: | Closed | Impact on me: | |
| Category: | MySQL Server | Severity: | S2 (Serious) |
| Version: | next-mr | OS: | Any |
| Assigned to: | Jon Olav Hauglid | CPU Architecture: | Any |
[22 Feb 2010 9:08]
Philip Stoev
Core and binary http://mysql-systemqa.s3.amazonaws.com/var-bug51376.zip Source: revision-id: alik@sun.com-20100220092730-paoo5t9gcajs5dq8 date: 2010-02-20 12:27:30 +0300 build-date: 2010-02-22 11:00:53 +0200 revno: 2936 branch-nick: mysql-next-mr
[22 Feb 2010 14:33]
John Embretsen
I am also observing this (on Solaris 10 x86 and SPARC, 64-bit), with current code from mysql-next-mr-bugfixing, revid luis.soares@sun.com-20100222002746-a2t4cikxmml1h4cm, during manual runs of the RQG test "rqg_info_schema". RQG command triggering the issue: perl runall.pl \ --grammar=conf/information_schema.yy \ --threads=10 \ --duration=300 \ --queries=100000 --reporters=Deadlock,ErrorLog,Backtrace,Shutdown \ --basedir=$CODE \ --mysqld=--log-output=file \ --mysqld=--loose-skip-safemalloc \ --mysqld=--loose-table-lock-wait-timeout=1 \ --mysqld=--loose-lock-wait-timeout=1 \ --mysqld=--loose-innodb-lock-wait-timeout=1
[22 Feb 2010 17:02]
Jon Olav Hauglid
Looks like a timeout error (ER_LOCK_WAIT_TIMEOUT) that's not propagated properly.
[23 Feb 2010 12:45]
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/101190 3105 Jon Olav Hauglid 2010-02-23 Bug #51376 Assert `! is_set()' failed in Diagnostics_area::set_ok_status on DROP FUNCTION This assert was caused by lock timeouts in accessing system tables to do an implicit REVOKE after executing DROP FUNCTION/PROCEDURE. In practice, this would only be likely to happend with very low values for "lock_wait_timeout" (in the bug report 1 second was used). The patch for Bug#45225 introduced lock timeouts for metadata locks. This made it possible to get timeouts when accessing system tables. The bug here was that any timeout errors when executing an implicit REVOKE (which has to access serveral system tables) during DROP FUNCTION/PROCEDURE were ignored. This patch fixes the problem by making sure that any such timeout errors are propagated and reported to the client. Note that a followup patch for Bug#45225 currently in review, changes accessing of system tables such that the user-supplied timeout value is ignored and the maximum timeout value is used instead. (This will also apply for system threads.) Test case added to sp.test.
[2 Mar 2010 12:29]
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/102033 3120 Jon Olav Hauglid 2010-03-02 Bug #51376 Assert `! is_set()' failed in Diagnostics_area::set_ok_status on DROP FUNCTION This assert tests that the server is not trying to send "ok" to the client if an error has occured during statement processing. In this case, the assert was triggered by lock timeout errors when accessing system tables to do an implicit REVOKE after executing DROP FUNCTION/PROCEDURE. In practice, this would only be likely to happen with very low values for "lock_wait_timeout" (in the bug report 1 second was used). These errors were ignored and the server tried to send "ok" to the client, triggering the assert. The patch for Bug#45225 introduced lock timeouts for metadata locks. This made it possible to get timeouts when accessing system tables. Note that a followup patch for Bug#45225 pushed after this bug was reported, changed accessing of system tables such that the user-supplied timeout value is ignored and the maximum timeout value is used instead. This exact bug was therefore only noticeable in the period between the initial Bug#45225 patch and the followup patch. However, the same problem could occur for any errors during revoking of privileges - not just timeouts. This patch fixes the problem by making sure that any errors during revoking of privileges are reported to the client. Test case added to sp-destruct.test. Since the original bug is not reproducable now that system tables are accessed using a a long timeout value, this test instead calls DROP FUNCTION with a grant system table missing.
[3 Mar 2010 9:25]
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/102152 3120 Jon Olav Hauglid 2010-03-03 Bug #51376 Assert `! is_set()' failed in Diagnostics_area::set_ok_status on DROP FUNCTION This assert tests that the server is not trying to send "ok" to the client if an error has occured during statement processing. In this case, the assert was triggered by lock timeout errors when accessing system tables to do an implicit REVOKE after executing DROP FUNCTION/PROCEDURE. In practice, this was only likely to happen with very low values for "lock_wait_timeout" (in the bug report 1 second was used). These errors were ignored and the server tried to send "ok" to the client, triggering the assert. The patch for Bug#45225 introduced lock timeouts for metadata locks. This made it possible to get timeouts when accessing system tables. Note that a followup patch for Bug#45225 pushed after this bug was reported, changed accessing of system tables such that the user-supplied timeout value is ignored and the maximum timeout value is used instead. This exact bug was therefore only noticeable in the period between the initial Bug#45225 patch and the followup patch. However, the same problem could occur for any errors during revoking of privileges - not just timeouts. This patch fixes the problem by making sure that any errors during revoking of privileges are reported to the client. Test case added to sp-destruct.test. Since the original bug is not reproducable now that system tables are accessed using a a long timeout value, this test instead calls DROP FUNCTION with a grant system table missing.
[3 Mar 2010 9:36]
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:53]
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)
[7 Mar 2010 0:55]
Paul DuBois
Not in any released version since this depends on the new lock_wait_timeout variable. No changelog entry needed.
Description: When executing a concurrent DDL workload, mysqld asserted as follows: mysqld: sql_error.cc:359: void Diagnostics_area::set_ok_status(THD*, ulonglong, ulonglong, const char*): Assertion `! is_set()' failed. #6 0x000000315a42bec9 in __assert_fail () from /lib64/libc.so.6 #7 0x00000000007094f6 in Diagnostics_area::set_ok_status (this=0x7f31d00e4ed0, thd=0x7f31d00e2488, affected_rows_arg=0, last_insert_id_arg=0, message_arg=0x0) at sql_error.cc:359 #8 0x000000000055464a in my_ok (thd=0x7f31d00e2488, affected_rows=0, id=0, message=0x0) at sql_class.h:2722 #9 0x000000000065b835 in mysql_execute_command (thd=0x7f31d00e2488) at sql_parse.cc:4222 #10 0x000000000065c832 in mysql_parse (thd=0x7f31d00e2488, inBuf=0x2e62a58 "DROP FUNCTION IF EXISTS testdb_N . f1_1_N", length=41, found_semicolon=0x7f31dc12bee0) at sql_parse.cc:5581 #11 0x000000000065d44b in dispatch_command (command=COM_QUERY, thd=0x7f31d00e2488, packet=0x7f31d01360f9 "DROP FUNCTION IF EXISTS testdb_N . f1_1_N ", packet_length=42) at sql_parse.cc:1023 #12 0x000000000065e8eb in do_command (thd=0x7f31d00e2488) at sql_parse.cc:709 #13 0x000000000064cacb in do_handle_one_connection (thd_arg=0x7f31d00e2488) at sql_connect.cc:1174 #14 0x000000000064cb9a in handle_one_connection (arg=0x7f31d00e2488) at sql_connect.cc:1113 #15 0x000000315b0073da in start_thread () from /lib64/libpthread.so.0 #16 0x000000315a4e627d in clone () from /lib64/libc.so.6 This has happened either on DROP FUNCTION or on DROP PROCEDURE. How to repeat: I am under the impression that Diagnostics_area assertions are fixable based on core file alone, so the core will be uploaded shortly.