Bug #26159 select statement crashes mysql server
Submitted: 7 Feb 2007 19:16 Modified: 21 Feb 2007 3:05
Reporter: Axel Schwenke Email Updates:
Status: Closed Impact on me:
Category:MySQL Server: Optimizer Severity:S1 (Critical)
Version:5.1.15-bk, 5.0.36-bk OS:Linux (Linux)
Assigned to: Igor Babaev CPU Architecture:Any
Tags: bfsm_2007_02_15

[7 Feb 2007 19:16] Axel Schwenke
The following simple SELECT crashes the MySQL server.

How to repeat:
  `id` int(11) NOT NULL,
  `name` varchar(20) NOT NULL,
  `dept` varchar(20) NOT NULL,
  `age` tinyint(3) unsigned NOT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `EMP_key` (`name`,`dept`)

/* fill in some data */

select distinct EMP.name, EMP.dept from EMP where (EMP.name='abc');

Suggested fix:
Make the server not crash
[9 Feb 2007 9:45] Axel Schwenke
How to repeat:

shell> mysql test
mysql> \. testcase.sql
[9 Feb 2007 14:19] MySQL Verification Team
5.0.36 stack

Attachment: 5.0.36_windows_stack.txt (text/plain), 2.46 KiB.

[9 Feb 2007 19:58] Axel Schwenke
Shanes stack trace suggests this is a bug in the optimizer
[10 Feb 2007 8:11] MySQL Verification Team
some additional test results:

5.0.36 crashes
5.0.27 crashes
5.0.26 crashes
5.0.24a crashes
5.0.24 crashes
5.0.22 doesn't crash
5.0.21 crashes
5.0.20 crashes
5.0.19 crashes
5.0.18 crashes
5.0.16 crashes
5.0.15 crashes
5.0.13 crashes

4.1.21 doesn't crash
4.1.20 doesn't crash
[11 Feb 2007 7:52] 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:


ChangeSet@1.2410, 2007-02-10 23:55:56-08:00, igor@olga.mysql.com +3 -0
  Fixed bug #26159.
  A wrong order of statements in QUICK_GROUP_MIN_MAX_SELECT::reset
  caused a crash when a query with DISTINCT was executed by a loose scan
  for an InnoDB table that had been emptied.
[14 Feb 2007 10:33] Igor Babaev
The fix has been pushed to 5.0.36 and 5.1.16-beta.
[21 Feb 2007 3:05] Paul DuBois
Noted in 5.0.36, 5.1.16 changelogs.

DISTINCT queries that were executed using a loose scan for an InnoDB
table that had been emptied caused a server crash.