MySQL Bugs: #40494: MYSQL server crashes on range access with partitioning and order by

Bug #40494	MYSQL server crashes on range access with partitioning and order by
Submitted:	4 Nov 2008 11:51	Modified:	10 Nov 2008 14:35
Reporter:	Marc Isambart	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Server: Partitions	Severity:	S1 (Critical)
Version:	5.1.29/6.0	OS:	Any
Assigned to:	Mattias Jonsson	CPU Architecture:	Any
Tags:	crash, order, partitioning, range

Description:
This is a case where MySQL server 5.1.29 crashes on a SELECT when using a range WHERE condition with an ORDER BY on a partitioned table.

The same query works fine on MySQL server 5.1.26.

How to repeat:
We just need to consider 1 table, partitioned by range:

CREATE TABLE crash_test_tbl ( index1 integer NOT NULL, KEY(index1) )
ENGINE=MyISAM DEFAULT CHARSET=latin1
PARTITION BY RANGE(index1) (
	PARTITION p1 VALUES LESS THAN (200)
);

Let's add enough data to the table:

INSERT INTO crash_test_tbl VALUES (2), (40), (40), (60), (70), (90), (199);

If we then try to execute the following query, the server crashes:

SELECT index1 FROM crash_test_tbl WHERE index1 BETWEEN 60 AND 95 ORDER BY index1 ASC;

Thank you for the bug report. Verified as described:

c:\dbs>c:\dbs\5.1\bin\mysqld --defaults-file=c:\dbs\5.1\my.ini --standalone --console
081104  9:54:21  InnoDB: Started; log sequence number 0 560240392
081104  9:54:21 [Note] Event Scheduler: Loaded 1 event
081104  9:54:21 [Note] c:\dbs\5.1\bin\mysqld: ready for connections.
Version: '5.1.30-nt-debug-log'  socket: ''  port: 3510  Source distribution
081104  9:56:08 - mysqld got exception 0xc0000005 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
We will try our best to scrape up some info that will hopefully help diagnose
the problem, but since we have already crashed, something is definitely wrong
and this may fail.

key_buffer_size=8388572
read_buffer_size=131072
max_used_connections=1
max_threads=151
threads_connected=1
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 337709 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

thd: 0x1ed7210
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
00462550    mysqld.exe!ha_partition::handle_ordered_next()[ha_partition.cc:4520]
004615A5    mysqld.exe!ha_partition::read_range_next()[ha_partition.cc:4089]
00473F8D    mysqld.exe!handler::read_multi_range_next()[handler.cc:4063]
0058945F    mysqld.exe!QUICK_RANGE_SELECT::get_next()[opt_range.cc:8400]
005A40E3    mysqld.exe!rr_quick()[records.cc:313]
006CA884    mysqld.exe!sub_select()[sql_select.cc:11060]
006CA3AE    mysqld.exe!do_select()[sql_select.cc:10811]
006B5B87    mysqld.exe!JOIN::exec()[sql_select.cc:2182]
006B6259    mysqld.exe!mysql_select()[sql_select.cc:2363]
006AFD79    mysqld.exe!handle_select()[sql_select.cc:269]
006765B9    mysqld.exe!execute_sqlcom_select()[sql_parse.cc:4828]
0066F1CC    mysqld.exe!mysql_execute_command()[sql_parse.cc:2136]
00678661    mysqld.exe!mysql_parse()[sql_parse.cc:5727]
0066D31E    mysqld.exe!dispatch_command()[sql_parse.cc:1152]
0066CA07    mysqld.exe!do_command()[sql_parse.cc:809]
0077D154    mysqld.exe!handle_one_connection()[sql_connect.cc:1115]
00845F16    mysqld.exe!pthread_start()[my_winthread.c:85]
009B5447    mysqld.exe!_threadstart()[thread.c:196]
7C80B713    kernel32.dll!GetModuleFileNameA()

This is probably sufficient (running all tests now...)

=== modified file 'sql/ha_partition.cc'
--- sql/ha_partition.cc	2008-10-06 13:14:20 +0000
+++ sql/ha_partition.cc	2008-11-04 14:14:58 +0000
@@ -4084,7 +4084,7 @@
 {
   DBUG_ENTER("ha_partition::read_range_next");
 
-  if (m_ordered)
+  if (m_ordered_scan_ongoing)
   {
     DBUG_RETURN(handle_ordered_next(table->record[0], eq_range));
   }

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/57803

2776 Mattias Jonsson	2008-11-04
      Bug#40494: MYSQL server crashes on range access with
      partitioning and order by
      
      Problem was that the first index read was unordered,
      and the next was ordered, resulting in use of
      uninitialized data
      
      Solution was to use the correct variable to see if
      the 'next' call should be ordered or not.

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/57818

2776 Mattias Jonsson	2008-11-04
      Bug#40494: MYSQL server crashes on range access with
      partitioning and order by
      Problem was that the first index read was unordered,
      and the next was ordered, resulting in use of
      uninitialized data.
      Solution was to use the correct variable to see if
      the 'next' call should be ordered or not.

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/57898

2776 Mattias Jonsson	2008-11-05
      Bug#40494: MYSQL server crashes on range access with partitioning and
      order by
      
      Problem was that the first index read was unordered,
      and the next was ordered, resulting in use of
      uninitialized data.
      
      Solution was to use the correct variable to see if
      the 'next' call should be ordered or not.

Pushed into 5.1.30  (revid:mattias.jonsson@sun.com-20081105145328-7a77eli6nav568w1) (version source revid:mattias.jonsson@sun.com-20081105145835-z8k97r54rya0ab2m) (pib:5)

pushed into mysql-5.1 (main)

Noted in 5.1.30 changelog.

A SELECT using a range WHERE condition with an ORDER BY on a
partitioned table caused a server crash.

Setting report to NDI pending push into 6.0.x.

Pushed into 6.0.8-alpha  (revid:mattias.jonsson@sun.com-20081105145328-7a77eli6nav568w1) (version source revid:kgeorge@mysql.com-20081106161825-9biri1v40v7b0kg3) (pib:5)

Also documented fix in 6.0.8 changelog. Closed.

Pushed into 5.1.30-ndb-6.2.17  (revid:mattias.jonsson@sun.com-20081105145328-7a77eli6nav568w1) (version source revid:tomas.ulin@sun.com-20081121161314-jhz3twf5xjt8stnh) (pib:5)

Pushed into 5.1.30-ndb-6.3.20  (revid:mattias.jonsson@sun.com-20081105145328-7a77eli6nav568w1) (version source revid:tomas.ulin@sun.com-20081121210644-zas6e9wa5kuj7d6f) (pib:5)

Pushed into 5.1.30-ndb-6.4.0  (revid:mattias.jonsson@sun.com-20081105145328-7a77eli6nav568w1) (version source revid:tomas.ulin@sun.com-20081126125835-5sohkzk2jjwpq1wp) (pib:5)

Bug: http://bugs.mysql.com/bug.php?id=41839 marked as duplicate of this one.