Bug #14851 | killing a long-running sub-query crashes mysqld | ||
---|---|---|---|
Submitted: | 11 Nov 2005 0:40 | Modified: | 14 Feb 2006 2:55 |
Reporter: | Timothy Smith | Email Updates: | |
Status: | Closed | Impact on me: | |
Category: | MySQL Server | Severity: | S1 (Critical) |
Version: | 4.1.16 | OS: | Any (all) |
Assigned to: | Oleksandr Byelkin | CPU Architecture: | Any |
[11 Nov 2005 0:40]
Timothy Smith
[14 Nov 2005 4:01]
Timothy Smith
I've repeated this with a simpler test case: create table a (id int primary key); create table b (id int unsigned not null); insert into a values (1); set @c = (select count(*) from a); insert into a select id + @c from a; -- Hit <Up><Enter> enough times to have 4096 rows in table a insert into b select id from a; -- This query will take forever; if you kill it from mysqladmin, -- it will crash mysqld with a seg fault select id from a where id in (select distinct id from b); Note that the "distinct" is important. If that is removed, then the query still takes forever, but it will not crash the server to kill it. Regards, Timothy
[14 Nov 2005 4:17]
Timothy Smith
I said "forever" in the previous comment, but that's not true. It just takes a long time....
[16 Nov 2005 15:13]
Oleksandr Byelkin
Thank you for bugreport! I can't repeat this bug any more. I tried following mysql-test script: create table t1 (id int primary key); create table t2 (id int unsigned not null); let $1 = 4097; while ($1) { eval insert into t1 values ($1); dec $1; } insert into t2 select id from t1; connect (con1, localhost, root,,); connection con1; create table t3 (kill_id int); insert into t3 values(connection_id()); select id from t1 where id in (select distinct id from t2); connection default; select ((@id := kill_id) - kill_id) from t3; sleep 3; kill @id; connection con1; -- error 2013 reap; disconnect con1; connection default; drop table t1, t2, t3; Also I tried your short test suite on my linux comp, and even full data test suite on debx86. server kill connection smoothly. If I lost something in the procedure please reopen bug with some comments.
[16 Nov 2005 22:09]
Timothy Smith
I could not repeat this with the mysqltest binary. However, I removed the "drop table" statement from the end of the test. After running the test (and it returned "ok"), I then connected with the 'mysql' client and ran the select from the test case, then suspended that mysql and did 'mysqladmin proc' and 'mysqladmin kill <ID>', and it crashed the server. I have set this up on mysqldev@production so you can use the exact setup I have. I just did 'bk pull' in my 4.1 tree, and built it with this command (as user tsmith): ################################################# cd ~/m/41/a ~/m/build > log 2>&1 make install ################################################# Then, as user mysqldev, I did: ################################################# d=/nfstmp1/tsmith/production/bug14851 rm -rf $d mkdir $d cd ~tsmith/m/x/41/bk ./bin/mysql_install_db --no-defaults --basedir="$PWD" --datadir="$d" ./libexec/mysqld --no-defaults --basedir="$PWD" \ --datadir="$d" --skip-networking --socket=mysql.sock & ./bin/mysqltest --no-defaults --socket="$d/mysql.sock" \ --user=root test <<'EOF' drop table if exists t1, t2, t3; create table t1 (id int primary key); create table t2 (id int unsigned not null); let $1 = 4097; while ($1) { eval insert into t1 values ($1); dec $1; } insert into t2 select id from t1; connect (con1, localhost, root,,); connection con1; create table t3 (kill_id int); insert into t3 values(connection_id()); select id from t1 where id in (select distinct id from t2); connection default; select ((@id := kill_id) - kill_id) from t3; sleep 3; kill @id; connection con1; -- error 2013 reap; disconnect con1; connection default; /* drop table t1, t2, t3; */ EOF ./bin/mysql --no-defaults --user=root \ --socket="$d/mysql.sock" test ################################################# -- Now at the mysql> prompt... select id from t1 where id in (select distinct id from t2); -- Now hit ^Z, and at the shell prompt: ################################################# ./bin/mysqladmin --no-defaults --user=root \ --socket="$d/mysql.sock" proc ./bin/mysqladmin --no-defaults --user=root \ --socket="$d/mysql.sock" kill 4 ################################################# Regards,
[16 Nov 2005 22:21]
Timothy Smith
log of a session showing the exact commands run as mysqldev@production
Attachment: typescript (application/octet-stream, text), 146.27 KiB.
[16 Nov 2005 22:32]
Timothy Smith
By the way, I tried this on 5.0.15 and it does *not* crash there. It seems that only 4.1 is affected. Timothy
[21 Nov 2005 15:24]
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/internals/32466
[21 Nov 2005 15:37]
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/internals/32468
[15 Jan 2006 20:09]
Konstantin Osipov
Approved with a few comments by email.
[18 Jan 2006 11: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/internals/33363
[18 Jan 2006 11:32]
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/internals/33364
[18 Jan 2006 11:49]
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/internals/33366
[12 Feb 2006 11:51]
Oleksandr Byelkin
bugfix pushed into 5.1.7, 5.0.19, 4.1.19 Problem was that killing a longruning query with subqueries may lead to a mysql server crash due to incorrect attempt to free resources in case of kill
[14 Feb 2006 2:55]
Paul DuBois
Noted in 4.1.19, 5.0.19, 5.1.7 changelogs. Killing a long-running query containing a subquery could cause a server crash. (Bug #14851)