MySQL Bugs: #16428: Simultaneous conflicting events lead to crash

Bug #16428	Simultaneous conflicting events lead to crash
Submitted:	12 Jan 2006 4:24	Modified:	24 May 2006 0:05
Reporter:	Peter Gulutzan	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Server: Stored Routines	Severity:	S3 (Non-critical)
Version:	5.1.6-alpha-debug	OS:	Linux (SUSE 10.0)
Assigned to:	Andrey Hristov	CPU Architecture:	Any

Description:
I have eight events which are certain to interfere with each other.
I say "set global event_scheduler = 1".
After a few seconds or a few minutes, never more than 10 minutes, crash.

How to repeat:

Execute these statements:

create event en4 on schedule every 1 microsecond do create table t (s1 int);
create event en2 on schedule every 1 second do drop table t;
create event en on schedule every 1 microsecond do create table t (s1 int);
create event en3 on schedule every 1 second do drop table t;
create event en5 on schedule every 1 second do insert into t values (5);
create event en6 on schedule every 1 second do delete from t;
create event en7 on schedule every 1 second do start transaction;
create event en8 on schedule every 1 second do commit;
set global event_scheduler = 1;

Wait 10 minutes.

after 1 to 10 minutes, mysqld crashes with the words
"safe_mutex: Trying to lock mutex at sql_base.cc, line 5886,
when the mutex was already locked at sql_table.cc, line 238
in thread T@10971616"

tested on 5.1.6-alfa (without debug) and server hardly hangs. Going to test on 5.1.5-debug

030412 12:45:36 [Note]     EVEX EXECUTING event test.en2 [EXPR:1]
030412 12:45:36 [Note]     EVEX EXECUTED event test.en2  [EXPR:1]. RetCode=0
mysqld got signal 11;

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/2737

Argh, bad bugreport

0x81cdb07 handle_segfault + 437
0xffffe420 _end + -142440304
(nil)
0x85935e2 safe_mutex_lock + 200
0x8220da0 remove_table_from_cache(THD*, char const*, char const*, unsigned int) + 554
0x81c810b lock_table_name(THD*, st_table_list*) + 845
0x81c8326 lock_table_names(THD*, st_table_list*) + 42
0x82d0787 mysql_rm_table_part2(THD*, st_table_list*, bool, bool, bool, bool) + 369
0x82d03d7 mysql_rm_table(THD*, st_table_list*, char, char) + 325
0x81eb468 mysql_execute_command(THD*) + 12068
0x833f2b5 sp_instr_stmt::exec_core(THD*, unsigned int*) + 17
0x833ee9a sp_lex_keeper::reset_lex_and_exec_core(THD*, unsigned int*, bool, sp_instr*) + 432
0x833f120 sp_instr_stmt::execute(THD*, unsigned int*) + 396
0x833bb7b sp_head::execute(THD*) + 1197
0x833cee6 sp_head::execute_procedure(THD*, List<Item>*) + 1514
0x8357454 Event_timed::execute(THD*, st_mem_root*) + 872
0x834fe89 event_executor_worker + 411
0x40173aa7 _end + 932830999
0x402a4c2e _end + 934080670

Should be retested after 17619 is closed.

I was not able to repeat with similar test case (using SECOND instead of MICROSECOND, as MICROSECOND interval is not supported) on 5.1.12-debug (ChangeSet@1.2169.1.11, 2006-05-23 14:35:18+10:00). It runs without crashes for 25+ minutes. Looks like the bug is fixed (or was MICROSECOND related).

Was fixed by the patch for bug#17619

Fixed in 5.1.11

Thank you for your bug report. This issue has been committed to our
source repository of that product and will be incorporated into the
next release.

If necessary, you can access the source repository and build the latest
available version, including the bugfix, yourself. More information 
about accessing the source trees is available at
    http://www.mysql.com/doc/en/Installing_source_tree.html

Additional info:

Documented bugfix in 5.1.11 changelog; updated Synopsis; closed.

NOTE: The original test case for this bug referenced a time interval (MICROSECOND) that is *not supported* for scheduled events. The issue was one of conflicting event actions.