| 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: | |
| Category: | MySQL Server: Optimizer | Severity: | S1 (Critical) |
| Version: | 6.0.9,5.4 | OS: | Any |
| Assigned to: | Assigned Account | CPU Architecture: | Any |
| Tags: | regression | ||
[6 Mar 2009 9:48]
MySQL Verification Team
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]
MySQL Verification Team
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]
Valeriy 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.
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;