| Bug #44171 | KILL ALTER EVENT can crash the server | ||
|---|---|---|---|
| Submitted: | 8 Apr 2009 23:35 | Modified: | 20 Nov 2010 18:15 |
| Reporter: | Zhenxing He | Email Updates: | |
| Status: | Closed | Impact on me: | |
| Category: | MySQL Server: DDL | Severity: | S3 (Non-critical) |
| Version: | 5.1,6.0 | OS: | Any |
| Assigned to: | Jon Olav Hauglid | CPU Architecture: | Any |
| Tags: | disabled | ||
[13 Apr 2009 6:33]
Sveta Smirnova
Thank you for the report. Verified as described. To repeat one should have option file with "--event-scheduler" in it. Also bug is repeatable not every time. I modified test as following to be able to repeat the problem easily: set global event_scheduler='on'; connect (master,127.0.0.1,root,,test,$MASTER_MYPORT,); connect (master1,127.0.0.1,root,,test,$MASTER_MYPORT,); connection master; let $connection_id= `SELECT CONNECTION_ID()`; show variables like '%EVENT%'; CREATE EVENT e1 ON SCHEDULE AT CURRENT_TIMESTAMP + INTERVAL 1 DAY DO INSERT INTO test.t1 VALUES (1); send ALTER EVENT e1 ON SCHEDULE AT CURRENT_TIMESTAMP + INTERVAL 2 DAY; connection master1; # kill the query that is waiting --disable_query_log eval kill query $connection_id; --enable_query_log drop event e1;
[26 Aug 2010 8:31]
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/116833 3122 Jon Olav Hauglid 2010-08-26 Bug #44171 KILL ALTER EVENT can crash the server This assert could be triggered if ALTER EVENT failed to load the event after altering it. Failing to load the event could for example happen because of KILL QUERY. The assert tested that the result of a failed load_named_event() was OP_LOAD_ERROR. However since load_named_event() returns bool, this assert did not make any sense. This patch therefore removes the assert, fixing the problem. The patch also removes enum_events_error_code since it was unused. Test case added to events_sync.test.
[26 Aug 2010 10:02]
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/116842 3122 Jon Olav Hauglid 2010-08-26 Bug #44171 KILL ALTER EVENT can crash the server This assert could be triggered if ALTER EVENT failed to load the event after altering it. Failing to load the event could for example happen because of KILL QUERY. The assert tested that the result of a failed load_named_event() was OP_LOAD_ERROR. However since load_named_event() returns bool, this assert did not make any sense. This patch therefore removes the assert, fixing the problem. The patch also removes enum_events_error_code since it was unused. No test case added. The bug fix is trivial and this bug was easily detected by RQG tests. Further, adding a MTR test case for this bug would require adding sync points to make the test case repeatable.
[26 Aug 2010 10:24]
Jon Olav Hauglid
Pushed to mysql-5.5-runtime.
[9 Nov 2010 19:46]
Bugs System
Pushed into mysql-5.5 5.5.7-rc (revid:sunanda.menon@sun.com-20101109182959-otkxq8vo2dcd13la) (version source revid:marko.makela@oracle.com-20100824081003-v4ecy0tga99cpxw2) (merge vers: 5.1.50) (pib:21)
[12 Nov 2010 1:52]
Paul DuBois
Noted in 5.5.7 changelog. If ALTER EVENT failed to load an event after altering it, an assertion could be raised. This could occur, for example, if ALTER EVENT was killed with KILL QUERY.
[13 Nov 2010 16:07]
Bugs System
Pushed into mysql-trunk 5.6.99-m5 (revid:alexander.nozdrin@oracle.com-20101113155825-czmva9kg4n31anmu) (version source revid:marko.makela@oracle.com-20100824081003-v4ecy0tga99cpxw2) (merge vers: 5.1.50) (pib:21)
[13 Nov 2010 16:36]
Bugs System
Pushed into mysql-next-mr (revid:alexander.nozdrin@oracle.com-20101113160336-atmtmfb3mzm4pz4i) (version source revid:marko.makela@oracle.com-20100824081003-v4ecy0tga99cpxw2) (pib:21)
Description: Using a debug build server and try to KILL the thread that is executing ALTER EVENT query can crash the server. Here is the backtrace I got from 5.1: #0 0x00007f17a380d1e6 in pthread_kill () from /lib/libpthread.so.0 #1 0x0000000000b14f07 in my_write_core (sig=6) at stacktrace.c:310 #2 0x00000000006b5ed6 in handle_segfault (sig=6) at mysqld.cc:2536 #3 <signal handler called> #4 0x00007f17a29d0015 in raise () from /lib/libc.so.6 #5 0x00007f17a29d1b83 in abort () from /lib/libc.so.6 #6 0x00007f17a29c8d89 in __assert_fail () from /lib/libc.so.6 #7 0x00000000008b53c2 in Events::update_event (thd=0x7f179c08ab58, parse_data=0x19e0c38, new_dbname=0x0, new_name=0x0) at events.cc:539 #8 0x00000000006ccaac in mysql_execute_command (thd=0x7f179c08ab58) at sql_parse.cc:3730 #9 0x00000000006d0c8a in mysql_parse (thd=0x7f179c08ab58, inBuf=0x19e0ad8 "ALTER EVENT e1\nON SCHEDULE AT CURRENT_TIMESTAMP + INTERVAL 2 DAY", length=64, found_semicolon=0x40b7abf8) at sql_parse.cc:5929 #10 0x00000000006d1a78 in dispatch_command (command=COM_QUERY, thd=0x7f179c08ab58, packet=0x7f179c08d4b9 "ALTER EVENT e1\nON SCHEDULE AT CURRENT_TIMESTAMP + INTERVAL 2 DAY", packet_length=64) at sql_parse.cc:1216 #11 0x00000000006d2edd in do_command (thd=0x7f179c08ab58) at sql_parse.cc:857 #12 0x00000000006bf6df in handle_one_connection (arg=0x7f179c08ab58) at sql_connect.cc:1115 #13 0x00007f17a38083ea in start_thread () from /lib/libpthread.so.0 #14 0x00007f17a2a83cbd in clone () from /lib/libc.so.6 #15 0x0000000000000000 in ?? () How to repeat: Run the follow test several times: ------------------------------------------------------------------ connect (master,127.0.0.1,root,,test,$MASTER_MYPORT,); connect (master1,127.0.0.1,root,,test,$MASTER_MYPORT,); connection master; let $connection_id= `SELECT CONNECTION_ID()`; CREATE EVENT e1 ON SCHEDULE AT CURRENT_TIMESTAMP + INTERVAL 1 DAY DO INSERT INTO test.t1 VALUES (1); send ALTER EVENT e1 ON SCHEDULE AT CURRENT_TIMESTAMP + INTERVAL 2 DAY; connection master1; # kill the query that is waiting eval kill query $connection_id; ---------------------------------------------------------------- Suggested fix: By checking the code, the problem is caused by the following lines(file events.cc, function Events::update_event): else if ((ret= db_repository->load_named_event(thd, dbname, name, new_element))) { DBUG_ASSERT(ret == OP_LOAD_ERROR); delete new_element; } The return value of method 'Event_db_repository::load_named_event' is bool, it will return 1 when it fails (e.g. being KILLED in this case), while the value of OP_LOAD_ERROR is 5, and caused the assertion failure. I think the assertion is wrong and should be removed.