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

[12 Jan 2006 4:24] Peter Gulutzan
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"
[12 Jan 2006 7:17] Aleksey Kishkin
tested on 5.1.6-alfa (without debug) and server hardly hangs. Going to test on 5.1.5-debug
[12 Jan 2006 14:45] Miguel Solorzano
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;
[16 Feb 2006 15:31] Andrey Hristov
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
[16 Feb 2006 15:32] Andrey Hristov
Argh, bad bugreport
[8 Mar 2006 12:03] Andrey Hristov
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
[18 Apr 2006 19:00] Andrey Hristov
Should be retested after 17619 is closed.
[23 May 2006 11:26] Valeriy Kravchuk
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).
[23 May 2006 11:33] Andrey Hristov
Was fixed by the patch for bug#17619
[23 May 2006 11:33] Andrey Hristov
Fixed in 5.1.11
[24 May 2006 0:05] Jon Stephens
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.