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)
Portions of this website are copyright © 2001, 2002 The PHP Group
Page generated in 0.045 sec. using MySQL 8.4.7-u6-cloud
Timestamp references displayed by the system are UTC.
Content reproduced on this site is the property of the
respective copyright holders.
It is not reviewed in advance
by Oracle and does not necessarily represent the opinion of
Oracle or any other party.