Bug #43447 Crash when executing SELECT ... LIMIT n FOR UPDATE query
Submitted: 6 Mar 2009 9:45 Modified: 1 Jul 2009 14:19
Reporter: John Embretsen Email Updates:
Status: Duplicate Impact on me:
None 
Category:MySQL Server: Optimizer Severity:S1 (Critical)
Version:6.0.9,5.4 OS:Any
Assigned to: Evgeny Potemkin
Tags: regression
Triage: Triaged: D1 (Critical)

[6 Mar 2009 9:45] John Embretsen
Description:
While executing a mysql-stress-test test suite, the MySQL server (6.0) crashed when executing the following query against an InnoDB table with ~1000 rows:

SELECT * FROM t1 WHERE `int1_key` BETWEEN 981 AND 1030 ORDER BY `int1_key`, `pk` LIMIT 10 FOR UPDATE;

(`int1_key` is an indexed INT column)

The crash occurs even with no concurrency (single thread), using latest mysql-6.0 bzr source. Also observed against MySQL Server 6.0.8.

Platform: Ubunutu 8.10 (32-bit) and Red Hat Enterprise Linux 5.2 (64-bit).

Crash does not occur with Falcon or PBXT as storage engine.
Crash does not occur with MySQL Server 5.1.32.

090306 10:39:05 - mysqld got signal 11 ;
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=8388600
read_buffer_size=131072
max_used_connections=1
max_threads=151
thread_count=1
connection_count=1
It is possible that mysqld could use up to 
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 337763 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

thd: 0xa93f938
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...
stack_bottom = 0xacfedfa8 thread_stack 0x30c00
./bin/mysqld(my_print_stacktrace+0x22) [0x86d4842]
./bin/mysqld(handle_segfault+0x39f) [0x825f11f]
[0xb807a400]
./bin/mysqld(row_search_for_mysql+0x16e0) [0x85ef670]
./bin/mysqld(ha_innobase::index_read(unsigned char*, unsigned char const*, unsigned int, ha_rkey_function)+0x166) [0x8560816]
./bin/mysqld(handler::read_range_first(st_key_range const*, st_key_range const*, bool, bool)+0xb7) [0x8358a17]
./bin/mysqld(DsMrr_impl::dsmrr_next(handler*, char**)+0xf7) [0x835c667]
./bin/mysqld(ha_innobase::multi_range_read_next(char**)+0x21) [0x855cf41]
./bin/mysqld(QUICK_RANGE_SELECT::get_next()+0x39) [0x8338b09]
./bin/mysqld [0x83519ed]
./bin/mysqld(sub_select(JOIN*, st_join_table*, bool)+0x81) [0x82cdb21]
./bin/mysqld [0x82ce05f]
./bin/mysqld(JOIN::exec()+0xa23) [0x82e1023]
./bin/mysqld(mysql_select(THD*, Item***, TABLE_LIST*, unsigned int, List<Item>&, Item*, unsigned int, st_order*, st_order*, Item*, st_order*, unsigned long long, select_result*, st_select_lex_unit*, st_select_lex*)+0x1c1) [0x82dcfd1]
./bin/mysqld(handle_select(THD*, LEX*, select_result*, unsigned long)+0x15e) [0x82e2b7e]
./bin/mysqld [0x826d9fa]
./bin/mysqld(mysql_execute_command(THD*)+0x22c6) [0x8272766]
./bin/mysqld(mysql_parse(THD*, char const*, unsigned int, char const**)+0x35b) [0x8276fab]
./bin/mysqld(dispatch_command(enum_server_command, THD*, char*, unsigned int)+0xa37) [0x8277ea7]
./bin/mysqld(do_command(THD*)+0xc4) [0x8278d24]
./bin/mysqld(handle_one_connection+0x1e8) [0x8269798]
/lib/tls/i686/cmov/libpthread.so.0 [0xb801450f]
/lib/tls/i686/cmov/libc.so.6(clone+0x5e) [0xb7e317ee]
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort...
thd->query at 0xaa57298 = SELECT * FROM t1 WHERE `int1_key` BETWEEN 981 AND 1030 ORDER BY `int1_key`, `pk` LIMIT 10 FOR UPDATE
thd->thread_id=1
thd->killed=NOT_KILLED

How to repeat:
CREATE TABLE t1 (
 `pk` INTEGER AUTO_INCREMENT NOT NULL,
 `id` INTEGER NOT NULL,
 `int1` INTEGER,
 `int1_key` INTEGER,
 `int1_unique` INTEGER,
 `int2` INTEGER,
 `int2_key` INTEGER,
 `int2_unique` INTEGER,
 `for_update` BOOLEAN,
 `timestamp` TIMESTAMP,
 `connection_id` INTEGER,
 `thread_id` INTEGER,
 `is_uncommitted` BOOLEAN,
 `is_consistent` BOOLEAN,
 KEY (`id`),
 KEY (`int1_key`),
 KEY (`int2_key`),
 UNIQUE (`int1_unique`),
 UNIQUE (`int2_unique`),
 PRIMARY KEY (`pk`)
) Engine = InnoDB;

## Procedure for inserting the value 1000 into integer fieds, "rows" times.

delimiter //

eval CREATE PROCEDURE insertRows(rows INT)
BEGIN
  SET @n = 1;
  REPEAT
    INSERT INTO t1 (`id`, `int1`, `int1_key`, `int1_unique`,
                    `int2`, `int2_key`, `int2_unique`,
                    `for_update`, `connection_id`, `thread_id`,
                    `is_uncommitted`, `is_consistent`)
       VALUES (0, 1000, 1000, @n,
               -1000, -1000, -@n,
               0, CONNECTION_ID(), 0,
               0, 1);
    SET @n = @n + 1;
  UNTIL @n > rows
  END REPEAT;
END;
//

delimiter ;

## Insert 1000 rows.
CALL insertRows(1000);

SET autocommit = 0;

START TRANSACTION;

# Crash should happen here:
SELECT * FROM t1 WHERE `int1_key` BETWEEN 981 AND 1030 ORDER BY `int1_key`, `pk` LIMIT 10 FOR UPDATE;
[6 Mar 2009 9:48] Shane Bester
is this really bug #36981 ?
[6 Mar 2009 10:18] John Embretsen
Shane: Thanks, that could very well be the same bug. Using

set optimizer_use_mrr='disable';
set engine_condition_pushdown=off;

makes the test pass.

I will leave it to someone else to verify if this is a duplicate or not, as I am not totally sure and I do not have the time to investigate further right now.
[6 Mar 2009 11:44] Miguel Solorzano
How Shane said looks a duplicate (similar call stack):

090306  8:35:11 [Note] c:\dbs\6.0\bin\mysqld: ready for connections.
Version: '6.0.10-alpha-Win x86-64 bzr revno:3036-log'  socket: ''  port: 3600  Source distribution
090306  8:40:41 - 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=8384512
read_buffer_size=131072
max_used_connections=1
max_threads=151
thread_count=1
connection_count=1
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 338184 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

thd: 0x3cceb80
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...
000000014036730B    mysqld.exe!row_sel_field_store_in_mysql_format()[row0sel.c:2464]
00000001403676FA    mysqld.exe!row_sel_store_mysql_rec()[row0sel.c:2677]
0000000140369515    mysqld.exe!row_search_for_mysql()[row0sel.c:4143]
0000000140354572    mysqld.exe!ha_innobase::index_read()[ha_innodb.cc:4480]
0000000140023967    mysqld.exe!handler::index_read_map()[handler.h:1784]
0000000140032EBD    mysqld.exe!handler::read_range_first()[handler.cc:5049]
0000000140352BE2    mysqld.exe!ha_innobase::read_range_first()[ha_innodb.cc:8573]
00000001400302F0    mysqld.exe!handler::multi_range_read_next()[handler.cc:4331]
00000001400DFED4    mysqld.exe!QUICK_RANGE_SELECT::get_next()[opt_range.cc:8560]
00000001400F407A    mysqld.exe!rr_quick()[records.cc:322]
00000001401B4F8C    mysqld.exe!sub_select()[sql_select.cc:16226]
00000001401B619C    mysqld.exe!do_select()[sql_select.cc:15789]
00000001401BB358    mysqld.exe!JOIN::exec()[sql_select.cc:2882]
00000001401BE505    mysqld.exe!mysql_select()[sql_select.cc:3064]
00000001401BE916    mysqld.exe!handle_select()[sql_select.cc:314]
0000000140170596    mysqld.exe!execute_sqlcom_select()[sql_parse.cc:4758]
0000000140173C80    mysqld.exe!mysql_execute_command()[sql_parse.cc:2063]
0000000140179028    mysqld.exe!mysql_parse()[sql_parse.cc:5757]
0000000140179A6A    mysqld.exe!dispatch_command()[sql_parse.cc:1011]
000000014017A89C    mysqld.exe!do_command()[sql_parse.cc:691]
0000000140219101    mysqld.exe!handle_one_connection()[sql_connect.cc:1146]
00000001402A6C9E    mysqld.exe!pthread_start()[my_winthread.c:63]
000000014056A387    mysqld.exe!_callthreadstartex()[threadex.c:348]
000000014056A45F    mysqld.exe!_threadstartex()[threadex.c:326]
0000000077BD495D    kernel32.dll!BaseThreadInitThunk()
0000000077D08791    ntdll.dll!RtlUserThreadStart()
Trying to get some variables.
[6 Mar 2009 11:47] Valerii Kravchuk
Verified just as described with 6.0.9 also. While both this and Shane's bug are clearly related to the new MRR feature and InnoDB, I am not sure they are duplicates.
[1 Jul 2009 14:19] Evgeny Potemkin
Duplicate of the bug#45029.