MySQL Bugs: #40992: InnoDB: Crash when index_condition

Bug #40992	InnoDB: Crash when index_condition_pushdown is on
Submitted:	24 Nov 2008 19:14	Modified:	26 Feb 2010 9:57
Reporter:	Paul DuBois	Email Updates:
Status:	Duplicate	Impact on me:	None
Category:	MySQL Server: Optimizer	Severity:	S3 (Non-critical)
Version:	6.0 bzr	OS:	Any
Assigned to:	Assigned Account	CPU Architecture:	Any
Tags:	index_condition_pushdown, optimizer_switch

Description:
If I run the following script in mysql, the server crashes the second time. This occurs with the current bzr source tree, but *not* in 6.0.8, so it appears to be a recently introduced problem.

set global binlog_format=row;
use test;
drop table if exists t;
create table t (dummy int primary key, a int unique, b int) engine innodb;
insert into t values(1,1,1),(3,3,3),(5,5,5);
set session transaction isolation level read committed;
select @@tx_isolation;
start transaction;
select * from t where a > 2 for update;
commit;

The second time though, the crash appears to occur during the drop table statement.
The crash does not occur with repeatable read isolation level.

How to repeat:
Put the script in a file and run it twice:

mysql < script_file
mysql < script_file

set binlog_format=row seems to be unrelated, the crash at the 2nd execution of the supplied script happens anyway with the following stack:

#2  0xb7bf6a01 in abort () from /lib/tls/i686/cmov/libc.so.6
#3  0x08797d8d in mem_area_free (ptr=0xb017b028, pool=0x96e09b8)
    at mem/mem0pool.c:518
#4  0x08797074 in mem_heap_block_free (heap=0xb017b028, block=0xb017b028)
    at mem/mem0mem.c:524
#5  0x087962f1 in mem_heap_free_func (heap=0xb017b028, 
    file_name=0x8b78a76 "row/row0mysql.c", line=702)
    at ../../storage/innobase/include/mem0mem.ic:487
#6  0x087963db in mem_free_func (ptr=0xb017b068, 
    file_name=0x8b78a76 "row/row0mysql.c", line=702)
    at ../../storage/innobase/include/mem0mem.ic:543
#7  0x087af98a in row_prebuilt_free (prebuilt=0xb017be68)
    at row/row0mysql.c:702
#8  0x0874c2ff in ha_innobase::close (this=0x9c83f88)
    at handler/ha_innodb.cc:2504
#9  0x083a8484 in closefrm (table=0x9c838b0, free_share=true) at table.cc:2110
#10 0x08396155 in intern_close_table (table=0x9c838b0) at sql_base.cc:791
#11 0x083961a9 in free_cache_entry (table=0x9c838b0) at sql_base.cc:813
#12 0x08396451 in tdc_remove_table (thd=0x9c36ee0, 
    remove_type=TDC_RT_REMOVE_ALL, db=0x9c8cd90 "test", 
    table_name=0x9c8cb68 "t") at sql_base.cc:7640
---Type <return> to continue, or q <return> to quit---
#13 0x084a3687 in mysql_rm_table_part2 (thd=0x9c36ee0, tables=0x9c8cb90, 
    if_exists=true, drop_temporary=false, drop_view=false, 
    dont_log_query=false) at sql_table.cc:1592
#14 0x084a432f in mysql_rm_table (thd=0x9c36ee0, tables=0x9c8cb90, 
    if_exists=1 '\001', drop_temporary=0 '\0') at sql_table.cc:1490
#15 0x0834d106 in mysql_execute_command (thd=0x9c36ee0) at sql_parse.cc:3307
#16 0x0835229d in mysql_parse (thd=0x9c36ee0, 
    inBuf=0x9c8c8c0 "drop table if exists t", length=22, 
    found_semicolon=0xaab4ebf8) at sql_parse.cc:5719
#17 0x08352dff in dispatch_command (command=COM_QUERY, thd=0x9c36ee0, 
    packet=0x9c7d901 "drop table if exists t", packet_length=22)
    at sql_parse.cc:1006

Thank you for the bug report.

set binlog_format=row is relevant because of:

mysql> select * from t where a > 2 for update;
ERROR 1598 (HY000): Binary logging not possible. Message: Transaction level 'READ-COMMITTED' in InnoDB is not safe for binlog mode 'STATEMENT'

[obtained with 5.1], so the binlog_format has to be row by some means in order
for the test case to work.

results of my experiments:
5.1 - can't reproduce
6.0 r2919 with our current version of innodb code - can't reproduce
6.0 r2919 plain, MySQL's version of InnoDB code - SEGV in select, mrr involved, so as far as this bug is concerned, can't reproduce it, either
6.0 r2919 plain + disable MRR: still follows the same mrr code path
and crashes on select

In short, I can't reproduce it so I have a few questions:
- can you reproduce it with r2919?
- if so, what are your configuration parameters, OS, hardware characteristics,
and could you add 'explain select' for the quesry in your test case.

Assigning to Calvin but setting to 'Need Feedback'

I got the below call stack running the script command one time on Windows server:

081124 20:55:00 [Note] c:\dbs\6.0\bin\mysqld: ready for connections.
Version: '6.0.9-alpha-nt-debug-log'  socket: ''  port: 3600  Source distribution
081124 20:55:51 - 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
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 = 337753 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

thd: 0x36fd398
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...
00965E57    mysqld.exe!dict_col_copy_type()[dict0dict.ic:26]
00968877    mysqld.exe!dict_index_copy_types()[dict0dict.c:1550]
00939A14    mysqld.exe!ha_innobase::change_active_index()[ha_innodb.cc:4371]
00939FD8    mysqld.exe!ha_innobase::rnd_init()[ha_innodb.cc:4575]
0045888D    mysqld.exe!handler::ha_rnd_init()[handler.h:1516]
00474126    mysqld.exe!DsMrr_impl::dsmrr_init()[handler.cc:4374]
009402BA    mysqld.exe!ha_innobase::multi_range_read_init()[ha_innodb.cc:8358]
00590E56    mysqld.exe!QUICK_RANGE_SELECT::reset()[opt_range.cc:8435]
006CC9CF    mysqld.exe!join_init_read_record()[sql_select.cc:14553]
006CADDB    mysqld.exe!sub_select()[sql_select.cc:13723]
006CA95F    mysqld.exe!do_select()[sql_select.cc:13470]
006B2A20    mysqld.exe!JOIN::exec()[sql_select.cc:2835]
006B30C0    mysqld.exe!mysql_select()[sql_select.cc:3027]
006ABBDD    mysqld.exe!handle_select()[sql_select.cc:301]
00672847    mysqld.exe!execute_sqlcom_select()[sql_parse.cc:4731]
0066B92D    mysqld.exe!mysql_execute_command()[sql_parse.cc:2061]
006746BD    mysqld.exe!mysql_parse()[sql_parse.cc:5719]
00669D06    mysqld.exe!dispatch_command()[sql_parse.cc:1006]
0066956D    mysqld.exe!do_command()[sql_parse.cc:689]
0077A897    mysqld.exe!handle_one_connection()[sql_connect.cc:1156]
0085FC6D    mysqld.exe!pthread_start()[my_winthread.c:86]
00B9D377    mysqld.exe!_threadstart()[thread.c:196]
7C80B713    kernel32.dll!GetModuleFileNameA()
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort...
thd->query at 036FFE80=select * from t where a > 2 for update
thd->thread_id=1
thd->killed=NOT_KILLED
The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.

I've copied the previous comment with my comments below:

results of my experiments:
5.1 - can't reproduce

  Right. The problem does not occur in 5.1.

6.0 r2919 with our current version of innodb code - can't reproduce
6.0 r2919 plain, MySQL's version of InnoDB code - SEGV in select, mrr involved, so as far
as this bug is concerned, can't reproduce it, either

  This is what I am using (bzr tree, r2919)

6.0 r2919 plain + disable MRR: still follows the same mrr code path
and crashes on select

In short, I can't reproduce it so I have a few questions:
- can you reproduce it with r2919?
- if so, what are your configuration parameters, OS, hardware characteristics,
and could you add 'explain select' for the quesry in your test case.

  I see the problem both on Mac OS X (Leopard, Intel), and Gentoo Linux.  Here is the configuration
for one of my systems:

[mysqld]
log-warnings=2
secure-auth
event_scheduler=ON
myisam-recover=BACKUP,FORCE
lower_case_table_names=1
port=60009
socket=/var/mysql/60009/mysql.sock
log-output=FILE
general_log
general_log_file=qlog
log-bin=binlog
expire_logs_days=7
slow_query_log
slow_query_log_file=slowlog
pid-file=mysqld.pid
innodb_data_file_path = ibdata1:10M
ssl-ca=/var/mysql/sslinfo/cacert.pem
ssl-cert=/var/mysql/sslinfo/server-cert.pem
ssl-key=/var/mysql/sslinfo/server-key.pem

Here's the EXPLAIN for the select statement, although the crash occurs in the drop table:

*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        table: t
         type: range
possible_keys: a
          key: a
      key_len: 5
          ref: NULL
         rows: 1
        Extra: Using index condition; Using MRR

this is the MRR crash, in select. MRR crashes are I believe common knowledge
but what Paul reported and what is the subject of this bug is a crash
in DROPT TABLE which is a bit more interesting. On the other hand it's 
entirely possible that the previous SELECT did some damage to the memory 
so it crashed on the statement after the select.

I think I accidentally change status to OPEN, returning to Feedback.
So Miguel and I see  the crash in MRR while Paul is the only one
who sees the crash in DROP. Paul, could you disable MRR and reproduce it?
As you can see from my note MySQL still insists on following the MRR codepath
even when I set optimizer_use_mrr=disable.

Okay, I tried disabling MRR. Here's my test script:

set global optimizer_use_mrr=disable;
set global binlog_format=row;
use test;
drop table if exists t;
create table t (dummy int primary key, a int unique, b int) engine innodb;
insert into t values(1,1,1),(3,3,3),(5,5,5);
set session transaction isolation level read committed;
select @@tx_isolation;
start transaction;
explain select * from t where a > 2 for update;
select * from t where a > 2 for update;

(note that I also added an EXPLAIN statement).

On Mac OS X, I get a crash on the SELECT. Here's the end of the output:

mysql> explain select * from t where a > 2 for update;
*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        table: t
         type: range
possible_keys: a
          key: a
      key_len: 5
          ref: NULL
         rows: 1
        Extra: Using index condition; Using MRR
1 row in set (0.00 sec)

mysql> select * from t where a > 2 for update;
ERROR 2013 (HY000): Lost connection to MySQL server during query

I also tried this with REPEATABLE READ, and I get a crash that way, too.

On Gentoo Linux, I get no crash with the script, if I run it once. If I run it a second time, I get a crash in the DROP TABLE. (This occurs either with READ COMMITTED or REPEATABLE READ.)

the problem is that MRR code path seems to be followed even when 
optimizer_use_mrr is unset. Still Paul is the only one who sees a problem
in DROP. My experience with MRR shows it has strong memory corrupting properties
so in order to possibly isolate the DROP problem, if any, we need to
really disable MRR, make mysqld forget completely about it.
Maybe Calvin could prepare a patch for Paul to try on Gentoo?

Paul - please disable both engine_condition_pushdown and optimizer_use_mrr:

SET engine_condition_pushdown=OFF;
SET optimizer_use_mrr=’disable’;

I have found engine_condition_pushdown causes more problems.

My previous feedback was incorrect. My test script set the global value of optimizer_use_mrr, which affects only subsequent connections, not the current one.  Here is a revised script:

set optimizer_use_mrr=disable;
set global binlog_format=row;
use test;
drop table if exists t;
create table t (dummy int primary key, a int unique, b int) engine
innodb;
insert into t values(1,1,1),(3,3,3),(5,5,5);
set session transaction isolation level read committed;
select @@tx_isolation;
start transaction;
explain select * from t where a > 2 for update;
select * from t where a > 2 for update;

In this case, "using MRR" no longer appears in EXPLAIN output:

*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        table: t
         type: range
possible_keys: a
          key: a
      key_len: 5
          ref: NULL
         rows: 1
        Extra: Using index condition

However, the crash still occurs (it occurs both with READ COMMITTED and REPEATABLE READ, same results on Mac OS X and Gentoo Linux).

Now here are my results with engine_condition_pushdown disabled.  Test script:

set engine_condition_pushdown=OFF;
set optimizer_use_mrr=disable;
set global binlog_format=row;
use test;
drop table if exists t;
create table t (dummy int primary key, a int unique, b int) engine
innodb;
insert into t values(1,1,1),(3,3,3),(5,5,5);
set session transaction isolation level read committed;
select @@tx_isolation;
start transaction;
explain select * from t where a > 2 for update;
select * from t where a > 2 for update;

EXPLAIN output:

*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        table: t
         type: range
possible_keys: a
          key: a
      key_len: 5
          ref: NULL
         rows: 1
        Extra: Using where

And no crash occurs on Mac OS X (for either READ COMMITTED or REPEATABLE READ).
On Gentoo Linux, I see a crash with either isolation level.

I saw the same crash on Windows when engine_condition_pushdown is ON, but no crash when engine_condition_pushdown is OFF:

mysql> set optimizer_use_mrr=disable;
Query OK, 0 rows affected (0.00 sec)

mysql> SET engine_condition_pushdown=OFF;
Query OK, 0 rows affected (0.00 sec)

mysql> set global binlog_format=row;
Query OK, 0 rows affected (0.00 sec)

mysql> drop table if exists t;
Query OK, 0 rows affected (0.06 sec)

mysql> create table t (dummy int primary key, a int unique, b int) engine
    -> innodb;
Query OK, 0 rows affected (0.14 sec)

mysql> insert into t values(1,1,1),(3,3,3),(5,5,5);
Query OK, 3 rows affected (0.06 sec)
Records: 3  Duplicates: 0  Warnings: 0

mysql> set session transaction isolation level read committed;
Query OK, 0 rows affected (0.00 sec)

mysql> select @@tx_isolation;
+----------------+
| @@tx_isolation |
+----------------+
| READ-COMMITTED |
+----------------+
1 row in set (0.00 sec)

mysql> start transaction;
Query OK, 0 rows affected (0.00 sec)

mysql> explain select * from t where a > 2 for update;
+----+-------------+-------+-------+---------------+------+---------+------+----
--+-------------+
| id | select_type | table | type  | possible_keys | key  | key_len | ref  | row
s | Extra       |
+----+-------------+-------+-------+---------------+------+---------+------+----
--+-------------+
|  1 | SIMPLE      | t     | range | a             | a    | 5       | NULL |
1 | Using where |
+----+-------------+-------+-------+---------------+------+---------+------+----
--+-------------+
1 row in set (0.00 sec)

mysql> select * from t where a > 2 for update;
+-------+------+------+
| dummy | a    | b    |
+-------+------+------+
|     3 |    3 |    3 |
|     5 |    5 |    5 |
+-------+------+------+
2 rows in set (0.00 sec)

Paul - you still see a crash on Gentoo Linux, with the same stack?

I'm losing track of what happens when, so I undertook a more systematic test on Gentoo:

engine_condition_pushdown optimizer_use_mrr isolation result

OFF                       disable           RR        no crash
OFF                       disable           RC        no crash

OFF                       force             RR        no crash
OFF                       force             RC        no crash

ON                        disable           RR        crash 1st time (1)
ON                        disable           RC        crash 1st time (2)

ON                        force             RR        crash 2nd time (3)
ON                        force             RC        crash 2nd time (4)

I'll paste crash dumps 1-4 in separate comments.

crash dump 1:

stack_bottom = 0xad1cffa8 thread_stack 0x30c00
/var/mysql/60009/libexec/mysqld(my_print_stacktrace+0x22) [0x875055c]
/var/mysql/60009/libexec/mysqld(handle_segfault+0x2cd) [0x82d6bb2]
[0xffffe400]
/var/mysql/60009/libexec/mysqld(row_search_for_mysql+0x17ef) [0x86ea6f1]
/var/mysql/60009/libexec/mysqld(ha_innobase::index_read(unsigned char*,
unsigned char const*, unsigned int, ha_rkey_function)+0x1f0) [0x866ab9e]
/var/mysql/60009/libexec/mysqld(handler::index_read_map(unsigned char*,
unsigned char const*, unsigned long, ha_rkey_function)+0x62) [0x840c498]
/var/mysql/60009/libexec/mysqld(handler::read_range_first(st_key_range const*,
st_key_range const*, bool, bool)+0x168) [0x84054fa]
/var/mysql/60009/libexec/mysqld(ha_innobase::read_range_first(st_key_range
const*, st_key_range const*, bool, bool)+0x3b) [0x8661b47]
/var/mysql/60009/libexec/mysqld(handler::multi_range_read_next(char**)+0x141)
[0x8403739]
/var/mysql/60009/libexec/mysqld(DsMrr_impl::dsmrr_next(handler*, char**)+0x23)
[0x84062c7]
/var/mysql/60009/libexec/mysqld(ha_innobase::multi_range_read_next(char**)+0x25)
[0x8661cab]
/var/mysql/60009/libexec/mysqld(QUICK_RANGE_SELECT::get_next()+0x75)
[0x83e4bed]
/var/mysql/60009/libexec/mysqld [0x83fd87d]
/var/mysql/60009/libexec/mysqld [0x8350753]
/var/mysql/60009/libexec/mysqld(sub_select(JOIN*, st_join_table*, bool)+0x125)
[0x8353fcd]
/var/mysql/60009/libexec/mysqld [0x8361658]
/var/mysql/60009/libexec/mysqld(JOIN::exec()+0x2085) [0x8373dcf]
/var/mysql/60009/libexec/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*)+0x327) [0x836ee0e]
/var/mysql/60009/libexec/mysqld(handle_select(THD*, LEX*, select_result*,
unsigned long)+0x1ec) [0x83740cb]
/var/mysql/60009/libexec/mysqld [0x82e7393]
/var/mysql/60009/libexec/mysqld(mysql_execute_command(THD*)+0x81d) [0x82e897a]
/var/mysql/60009/libexec/mysqld(mysql_parse(THD*, char const*, unsigned int,
char const**)+0x22f) [0x82f0e46]
/var/mysql/60009/libexec/mysqld(dispatch_command(enum_server_command, THD*,
char*, unsigned int)+0x894) [0x82f186a]
/var/mysql/60009/libexec/mysqld(do_command(THD*)+0x23d) [0x82f2b23]
/var/mysql/60009/libexec/mysqld(handle_one_connection+0x11d) [0x82dfec7]
/lib/libpthread.so.0 [0xb8009170]
/lib/libc.so.6(clone+0x5e) [0xb7e23c0e]

crash dump 2:

stack_bottom = 0xad0a9fa8 thread_stack 0x30c00
/var/mysql/60009/libexec/mysqld(my_print_stacktrace+0x22) [0x875055c]
/var/mysql/60009/libexec/mysqld(handle_segfault+0x2cd) [0x82d6bb2]
[0xffffe400]
/var/mysql/60009/libexec/mysqld(row_search_for_mysql+0x17ef) [0x86ea6f1]
/var/mysql/60009/libexec/mysqld(ha_innobase::index_read(unsigned char*,
unsigned char const*, unsigned int, ha_rkey_function)+0x1f0) [0x866ab9e]
/var/mysql/60009/libexec/mysqld(handler::index_read_map(unsigned char*,
unsigned char const*, unsigned long, ha_rkey_function)+0x62) [0x840c498]
/var/mysql/60009/libexec/mysqld(handler::read_range_first(st_key_range const*,
st_key_range const*, bool, bool)+0x168) [0x84054fa]
/var/mysql/60009/libexec/mysqld(ha_innobase::read_range_first(st_key_range
const*, st_key_range const*, bool, bool)+0x3b) [0x8661b47]
/var/mysql/60009/libexec/mysqld(handler::multi_range_read_next(char**)+0x141)
[0x8403739]
/var/mysql/60009/libexec/mysqld(DsMrr_impl::dsmrr_next(handler*, char**)+0x23)
[0x84062c7]
/var/mysql/60009/libexec/mysqld(ha_innobase::multi_range_read_next(char**)+0x25)
[0x8661cab]
/var/mysql/60009/libexec/mysqld(QUICK_RANGE_SELECT::get_next()+0x75)
[0x83e4bed]
/var/mysql/60009/libexec/mysqld [0x83fd87d]
/var/mysql/60009/libexec/mysqld [0x8350753]
/var/mysql/60009/libexec/mysqld(sub_select(JOIN*, st_join_table*, bool)+0x125)
[0x8353fcd]
/var/mysql/60009/libexec/mysqld [0x8361658]
/var/mysql/60009/libexec/mysqld(JOIN::exec()+0x2085) [0x8373dcf]
/var/mysql/60009/libexec/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*)+0x327) [0x836ee0e]
/var/mysql/60009/libexec/mysqld(handle_select(THD*, LEX*, select_result*,
unsigned long)+0x1ec) [0x83740cb]
/var/mysql/60009/libexec/mysqld [0x82e7393]
/var/mysql/60009/libexec/mysqld(mysql_execute_command(THD*)+0x81d) [0x82e897a]
/var/mysql/60009/libexec/mysqld(mysql_parse(THD*, char const*, unsigned int,
char const**)+0x22f) [0x82f0e46]
/var/mysql/60009/libexec/mysqld(dispatch_command(enum_server_command, THD*,
char*, unsigned int)+0x894) [0x82f186a]
/var/mysql/60009/libexec/mysqld(do_command(THD*)+0x23d) [0x82f2b23]
/var/mysql/60009/libexec/mysqld(handle_one_connection+0x11d) [0x82dfec7]
/lib/libpthread.so.0 [0xb7ee3170]
/lib/libc.so.6(clone+0x5e) [0xb7cfdc0e]

crash dump 3:

stack_bottom = 0xad08afa8 thread_stack 0x30c00
/var/mysql/60009/libexec/mysqld(my_print_stacktrace+0x22) [0x875055c]
/var/mysql/60009/libexec/mysqld(handle_segfault+0x2cd) [0x82d6bb2]
[0xffffe400]
/lib/libc.so.6(abort+0x188) [0xb7c3eed8]
/var/mysql/60009/libexec/mysqld(mem_area_free+0x14f) [0x86c1740]
/var/mysql/60009/libexec/mysqld(mem_heap_block_free+0x9e) [0x86c0ccc]
/var/mysql/60009/libexec/mysqld(row_prebuilt_free+0x117) [0x86dfd68]
/var/mysql/60009/libexec/mysqld(ha_innobase::close()+0x5d) [0x8664c4f]
/var/mysql/60009/libexec/mysqld(closefrm(TABLE*, bool)+0x82) [0x8343c86]
/var/mysql/60009/libexec/mysqld(intern_close_table(TABLE*)+0xf3) [0x8332c59]
/var/mysql/60009/libexec/mysqld [0x8332cad]
/var/mysql/60009/libexec/mysqld(tdc_remove_table(THD*,
enum_tdc_remove_table_type, char const*, char const*)+0x207) [0x8332eec]
/var/mysql/60009/libexec/mysqld(mysql_rm_table_part2(THD*, TABLE_LIST*, bool,
bool, bool, bool)+0x308) [0x842d4cd]
/var/mysql/60009/libexec/mysqld(mysql_rm_table(THD*, TABLE_LIST*, char,
char)+0xe4) [0x842df48]
/var/mysql/60009/libexec/mysqld(mysql_execute_command(THD*)+0x4161)
[0x82ec2be]
/var/mysql/60009/libexec/mysqld(mysql_parse(THD*, char const*, unsigned int,
char const**)+0x22f) [0x82f0e46]
/var/mysql/60009/libexec/mysqld(dispatch_command(enum_server_command, THD*,
char*, unsigned int)+0x894) [0x82f186a]
/var/mysql/60009/libexec/mysqld(do_command(THD*)+0x23d) [0x82f2b23]
/var/mysql/60009/libexec/mysqld(handle_one_connection+0x11d) [0x82dfec7]
/lib/libpthread.so.0 [0xb7ec4170]
/lib/libc.so.6(clone+0x5e) [0xb7cdec0e]

crash dump 4:

stack_bottom = 0xad1a2fa8 thread_stack 0x30c00
/var/mysql/60009/libexec/mysqld(my_print_stacktrace+0x22) [0x875055c]
/var/mysql/60009/libexec/mysqld(handle_segfault+0x2cd) [0x82d6bb2]
[0xffffe400]
/lib/libc.so.6(abort+0x188) [0xb7d56ed8]
/var/mysql/60009/libexec/mysqld(mem_area_free+0x14f) [0x86c1740]
/var/mysql/60009/libexec/mysqld(mem_heap_block_free+0x9e) [0x86c0ccc]
/var/mysql/60009/libexec/mysqld(row_prebuilt_free+0x117) [0x86dfd68]
/var/mysql/60009/libexec/mysqld(ha_innobase::close()+0x5d) [0x8664c4f]
/var/mysql/60009/libexec/mysqld(closefrm(TABLE*, bool)+0x82) [0x8343c86]
/var/mysql/60009/libexec/mysqld(intern_close_table(TABLE*)+0xf3) [0x8332c59]
/var/mysql/60009/libexec/mysqld [0x8332cad]
/var/mysql/60009/libexec/mysqld(tdc_remove_table(THD*,
enum_tdc_remove_table_type, char const*, char const*)+0x207) [0x8332eec]
/var/mysql/60009/libexec/mysqld(mysql_rm_table_part2(THD*, TABLE_LIST*, bool,
bool, bool, bool)+0x308) [0x842d4cd]
/var/mysql/60009/libexec/mysqld(mysql_rm_table(THD*, TABLE_LIST*, char,
char)+0xe4) [0x842df48]
/var/mysql/60009/libexec/mysqld(mysql_execute_command(THD*)+0x4161)
[0x82ec2be]
/var/mysql/60009/libexec/mysqld(mysql_parse(THD*, char const*, unsigned int,
char const**)+0x22f) [0x82f0e46]
/var/mysql/60009/libexec/mysqld(dispatch_command(enum_server_command, THD*,
char*, unsigned int)+0x894) [0x82f186a]
/var/mysql/60009/libexec/mysqld(do_command(THD*)+0x23d) [0x82f2b23]
/var/mysql/60009/libexec/mysqld(handle_one_connection+0x11d) [0x82dfec7]
/lib/libpthread.so.0 [0xb7fdc170]
/lib/libc.so.6(clone+0x5e) [0xb7df6c0e]

Based on Paul's results, there is no crash when engine_condition_pushdown is off. Change the category to Server:Optimizer.

Mickael, thanks for your comments.

One remark on
 
  [25 Nov 0:44] Michael Izioumtchenko

  set binlog_format=row is relevant because of:

  mysql> select * from t where a > 2 for update;
  ERROR 1598 (HY000): Binary logging not possible. Message: Transaction level
  'READ-COMMITTED' in InnoDB is not safe for binlog mode 'STATEMENT'

  [obtained with 5.1], so the binlog_format has to be row by some means in order
  for the test case to work.

It has to be not `STATEMENT'. Therefore my comments " set binlog_format=row seems to be unrelated " not that incorrect (not to say the binlog_format is unrelated though :-)

cheers,

Andrei

this bug is really a duplicate of my bug #36981

I am not able to reproduce the crash that occurs when drop table is executed (crash case 3 & 4 above), only the crash that occurs when the select is executed (crash case 1 & 2 above) when using the latest source version from mysql-6.0-codebase-bugfixing. In order to reproduce the crash Index Condition Pushdown had to be enabled for InnoDB.

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

3686 Olav Sandstaa	2009-10-29
      Test case for Bug#40992 InnoDB: Crash when engine_condition_pushdown is on
      
      Converted original test case for Bug#40992 to MTR and simplified the test.
      Adding this test to the optimizer_unfixed_bugs test suite.
     @ mysql-test/suite/optimizer_unfixed_bugs/r/bug40992.result
        Test case for Bug#40992 InnoDB: Crash when engine_condition_pushdown is on
     @ mysql-test/suite/optimizer_unfixed_bugs/t/bug40992.test
        Test case for Bug#40992 InnoDB: Crash when engine_condition_pushdown is on

Test case pushed to mysql-6.0-codebase-bugfixing. Changing status back to "in progress".

Pushed into 6.0.14-alpha (revid:alik@sun.com-20091031081410-qkxmjsdzjmj840aq) (version source revid:olav@sun.com-20091029130256-cuh1ps3hukprdtz9) (merge vers: 6.0.14-alpha) (pib:13)

This crash is caused by memory corruption issues. I have found at least two issues:

1. Memory corruption caused by writing beyond an array:
=======================================================

Output from valgrind:

==30675== Invalid write of size 8
==30675==    at 0x8F01E0: build_template(row_prebuilt_struct*, THD*, TABLE*, ha_innobase*, unsigned) (ha_innodb.cc:3437)
==30675==    by 0x8F32F7: ha_innobase::change_active_index(unsigned) (ha_innodb.cc:4637)
==30675==    by 0x8F3466: ha_innobase::index_init(unsigned, bool) (ha_innodb.cc:4309)
==30675==    by 0x5812B3: handler::ha_index_init(unsigned, bool) (handler.h:1559)==30675==    by 0x7BD3C8: QUICK_RANGE_SELECT::reset() (opt_range.cc:8524)
==30675==    by 0x702DBD: join_init_read_record(st_join_table*) (sql_select.cc:17114)
==30675==    by 0x70653C: sub_select(JOIN*, st_join_table*, bool) (sql_select.cc:16307)
==30675==    by 0x7141EE: do_select(JOIN*, List<Item>*, TABLE*, Procedure*) (sql_select.cc:15870)
==30675==    by 0x731B3D: JOIN::exec() (sql_select.cc:2929)
==30675==    by 0x72C157: mysql_select(THD*, Item***, TABLE_LIST*, unsigned, List<Item>&, Item*, unsigned, st_order*, st_order*, Item*, st_order*, unsigned long long, select_result*, st_select_lex_unit*, st_select_lex*) (sql_select.cc:3120)
==30675==    by 0x731E76: handle_select(THD*, LEX*, select_result*, unsigned long) (sql_select.cc:307)
==30675==    by 0x6868A4: execute_sqlcom_select(THD*, TABLE_LIST*) (sql_parse.cc:4965)
==30675==    by 0x687905: mysql_execute_command(THD*) (sql_parse.cc:2156)
==30675==    by 0x68FB0D: mysql_parse(THD*, char const*, unsigned, char const**)
(sql_parse.cc:5979)
==30675==    by 0x690FEA: dispatch_command(enum_server_command, THD*, char*, unsigned) (sql_parse.cc:1076)
==30675==    by 0x6924B5: do_command(THD*) (sql_parse.cc:758)

This is identical to bug#43360.

2. Reading of uninitialized data
================================

Output from valgrind:

==17364== Thread 12:
==17364== Conditional jump or move depends on uninitialised value(s)
==17364==    at 0x95CD01: row_sel_store_mysql_rec (row0sel.c:2614)
==17364==    by 0x95F380: row_search_for_mysql (row0sel.c:4154)
==17364==    by 0x8F3692: ha_innobase::index_read(unsigned char*, unsigned char const*, unsigned, ha_rkey_function) (ha_innodb.cc:4515)
==17364==    by 0x7E5653: handler::index_read_map(unsigned char*, unsigned char const*, unsigned long, ha_rkey_function) (handler.h:1796)
==17364==    by 0x7DD42F: handler::read_range_first(st_key_range const*, st_key_range const*, bool, bool) (handler.cc:5138)
==17364==    by 0x8ED1CA: ha_innobase::read_range_first(st_key_range const*, st_key_range const*, bool, bool) (ha_innodb.cc:8712)
==17364==    by 0x7DB37D: handler::multi_range_read_next(char**) (handler.cc:4420)
==17364==    by 0x7DE76D: DsMrr_impl::dsmrr_next(char**) (handler.cc:4689)
==17364==    by 0x8ED3C1: ha_innobase::multi_range_read_next(char**) (ha_innodb.cc:8620)
==17364==    by 0x7B876E: QUICK_RANGE_SELECT::get_next() (opt_range.cc:8664)
==17364==    by 0x7D4129: rr_quick(READ_RECORD*) (records.cc:322)
==17364==    by 0x702E38: join_init_read_record(st_join_table*) (sql_select.cc:17118)
==17364==    by 0x70653C: sub_select(JOIN*, st_join_table*, bool) (sql_select.cc:16307)
==17364==    by 0x7141EE: do_select(JOIN*, List<Item>*, TABLE*, Procedure*) (sql_select.cc:15870)
==17364==    by 0x731B3D: JOIN::exec() (sql_select.cc:2929)
==17364==    by 0x72C157: mysql_select(THD*, Item***, TABLE_LIST*, unsigned, List<Item>&, Item*, unsigned, st_order*, st_order*, Item*, st_order*, unsigned long long, select_result*, st_select_lex_unit*, st_select_lex*) (sql_select.cc:3120)

This is identical to Bug#41996.

This bug is a duplicate of Bug#43360 and/or Bug#36981. I have verified that this crash does no longer occur after applying the fixes for these two bugs.

Test case for this bug is committed here:

  http://lists.mysql.com/commits/97367

Patch containing updated version of test case:

http://lists.mysql.com/commits/99022

Patch containing test case pushed to mysql-6.0-codebase-bugfixing with revision-id: olav@sun.com-20100226091930-qxvakxmcp6463t5w .

Closing this as duplicate of Bug#36981.

Pushed into 6.0.14-alpha (revid:alik@sun.com-20100306102742-yw9zzgw9ac5r65m5) (version source revid:bar@mysql.com-20100305074327-h09o5lw290s04lcf) (merge vers: 6.0.14-alpha) (pib:16)

Pushed into mysql-next-mr (revid:alik@sun.com-20100816062819-bluwgdq8q4xysmlg) (version source revid:alik@sun.com-20100816062612-enatdwnv809iw3s9) (pib:20)

Pushed into mysql-trunk 5.6.99-m5 (revid:alexander.nozdrin@oracle.com-20101113155825-czmva9kg4n31anmu) (version source revid:vasil.dimov@oracle.com-20100629074804-359l9m9gniauxr94) (merge vers: 5.6.99-m4) (pib:21)