| Bug #16593 | Deadlock or crash in stress test for case where triggers starting trigger | ||
|---|---|---|---|
| Submitted: | 18 Jan 2006 3:14 | Modified: | 23 Feb 2006 3:24 |
| Reporter: | Alexey Stroganov | Email Updates: | |
| Status: | Closed | Impact on me: | |
| Category: | MySQL Server | Severity: | S1 (Critical) |
| Version: | 5.0.17a-cert,5.0.18 | OS: | Any (ALL) |
| Assigned to: | Dmitry Lenev | CPU Architecture: | Any |
[18 Jan 2006 3:14]
Alexey Stroganov
[18 Jan 2006 3:15]
Alexey Stroganov
details in case of crash
------------------------------
thread 74
------------
(gdb) bt
#0 0xc0000000001017b0:0 in _lwp_kill+0x30 ()
from /usr/lib/hpux64/libpthread.so.1
#1 0xc0000000000b0cb0:0 in __vp_kill+0xb0 ()
from /usr/lib/hpux64/libpthread.so.1
#2 0xc0000000000c0b90:0 in __pthread_internal_kill+0xb0 ()
from /usr/lib/hpux64/libpthread.so.1
#3 0xc0000000000c0a20:0 in pthread_kill+0x2e0 ()
from /usr/lib/hpux64/libpthread.so.1
#4 0x40000000008a3880:0 in write_core+0xe0 ()
from /home/alexey/mysql-pro-cert-5.0.17a-hpux11.23-ia64-64bit/bin/mysqld
#5 0x4000000000514000:0 in handle_segfault (sig=0) at mysqld.cc:2057
#6 <signal handler called>
#7 0xc0000000003015b0:0 in kill+0x30 () from /usr/lib/hpux64/libc.so.1
#8 0xc0000000002267f0:0 in raise+0x30 () from /usr/lib/hpux64/libc.so.1
#9 0xc0000000002c2f50:0 in abort+0x250 () from /usr/lib/hpux64/libc.so.1
#10 0xc0000000001c13b0:0 in _assert+0x260 () from /usr/lib/hpux64/libc.so.1
#11 0x40000000004fe310:0 in wait_if_global_read_lock (thd=0x60000000021cec28,
abort_on_refresh=96, is_not_commit=96) at lock.cc:948
#12 0x40000000007ce330:0 in mysql_rm_table (thd=0x303ffffff,
tables=0x303ffffff, if_exists=0 '\000', drop_temporary=0 '\000')
at sql_table.cc:108
#13 0x400000000055bc80:0 in mysql_execute_command (thd=0x60000000021ce800)
at sql_parse.cc:3430
thread 73
------------
[Switching to thread 73 (system thread 823807)]
#0 0x40000000002e4130:2 in st_lex::link_first_table_back (this=0x303ffffff,
first=0x303ffffff, link_to_local=false) at sql_lex.cc:1991
1991 sql_lex.cc: No such file or directory.
(gdb) bt
#0 0x40000000002e4130:2 in st_lex::link_first_table_back (this=0x303ffffff,
first=0x303ffffff, link_to_local=false) at sql_lex.cc:1991
#1 0x40000000005578f0:0 in mysql_execute_command (thd=0x60000000021c62d0)
at sql_parse.cc:2909
#2 0x400000000054dd10:0 in mysql_parse (thd=0x0, inBuf=0x0, length=0)
at sql_parse.cc:5628
#3 0x4000000000548660:0 in dispatch_command+0x20c0 ()
from /home/alexey/mysql-pro-cert-5.0.17a-hpux11.23-ia64-64bit/bin/mysqld
#4 0x400000000054c270:0 in do_command (thd=0x0) at sql_parse.cc:1514
#5 0x400000000054b750:0 in handle_one_connection (arg=0x0)
at sql_parse.cc:1158
#6 0xc0000000000a1b20:0 in __pthread_bound_body+0x180 ()
from /usr/lib/hpux64/libpthread.so.1
thread 72
------------
[Switching to thread 72 (system thread 823806)]
#0 0xc0000000000a96e0:0 in pthread_self+0 ()
from /usr/lib/hpux64/libpthread.so.1
(gdb) bt
#0 0xc0000000000a96e0:0 in pthread_self+0 ()
from /usr/lib/hpux64/libpthread.so.1
#1 0x4000000000c14140:0 in sp_pcontext::find_cond (this=0x0, name=0x0,
scoped=0 '\000') at sp_pcontext.cc:291
#2 0x400000000091a9c0:0 in st_table_list::prepare_security (this=0x0, thd=0x0)
at table.cc:2417
#3 0x4000000000565b90:0 in mysql_execute_command (thd=0x60000000021b42d0)
at sql_parse.cc:4646
#4 0x400000000054dd10:0 in mysql_parse (thd=0x0, inBuf=0x0, length=0)
at sql_parse.cc:5628
#5 0x4000000000548660:0 in dispatch_command+0x20c0 ()
from /home/alexey/mysql-pro-cert-5.0.17a-hpux11.23-ia64-64bit/bin/mysqld
#6 0x400000000054c270:0 in do_command (thd=0x0) at sql_parse.cc:1514
#7 0x400000000054b750:0 in handle_one_connection (arg=0x0)
at sql_parse.cc:1158
#8 0xc0000000000a1b20:0 in __pthread_bound_body+0x180 ()
from /usr/lib/hpux64/libpthread.so.1
[18 Jan 2006 3:17]
Alexey Stroganov
Below is test case that cause deadlock or crash when it executed in stress mode:
let $engine_type=myisam;
--disable_abort_on_error
# Checking for triggers starting triggers (no direct requirement)
use test;
--disable_warnings
drop table if exists t1;
drop table if exists t2_3;
drop table if exists t2_4;
drop table if exists t3;
--enable_warnings
eval create table t1 (f1 integer) engine=$engine_type;
eval create table t2_3 (f1 integer) engine=$engine_type;
eval create table t2_4 (f1 integer) engine=$engine_type;
eval create table t3 (f1 integer) engine=$engine_type;
insert into t1 values (1);
delimiter //;
create trigger tr1 after insert on t1 for each row
BEGIN
insert into t2_3 (f1) values (new.f1+1);
insert into t2_4 (f1) values (new.f1+1);
END//
delimiter ;//
create trigger tr2_3 after insert on t2_3 for each row
insert into t3 (f1) values (new.f1+1000);
create trigger tr2_4 after insert on t2_4 for each row
insert into t3 (f1) values (new.f1+10000);
insert into t1 values (1);
select * from t3;
#Cleanup
--disable_warnings
drop trigger tr1;
drop trigger tr2_3;
drop trigger tr2_4;
drop table t1, t2_3, t2_4, t3;
--enable_warnings
[19 Jan 2006 2:24]
Alexey Stroganov
Ran test case against servers on Win and RHAS4. In both cases got deadlock.
[23 Jan 2006 12:30]
Alexey Stroganov
Added test suite for reproducing of registered issue. To run it you need: 1. Unpack attached archive in mysql-test directory tar xzfv suite-bug16593.tar.gz 2. Run following command: ./mysql-test-run --stress --stress-threads=10 --stress-test-count=1000 --stress-suite=bug16593 deadlock
[4 Feb 2006 9:40]
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/2148
[16 Feb 2006 13:20]
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/2728
[22 Feb 2006 20:09]
Dmitry Lenev
Hi! This bug was fixed in versions 5.0.19 and 5.1.8. In short, the deadlock/crash happened when execution of statement, which used stored functions or activated triggers, coincided with alteration of the tables used by these functions or triggers (in highly concurrent environment).
[23 Feb 2006 3:24]
Paul DuBois
Noted in 5.0.19, 5.1.8 changelogs.
In a highly concurrent environment, a server crash or deadlock
could result from execution of a statement that used stored
functions or activated triggers coincident with alteration of
the tables used by these functions or triggers. (Bug #16593)
