MySQL Bugs: #46004: Crash in row_sel_field_store_in_mysql

Bug #46004	Crash in row_sel_field_store_in_mysql_format on a SELECT + LIMIT
Submitted:	7 Jul 2009 12:33	Modified:	27 Sep 2010 11:16
Reporter:	Philip Stoev	Email Updates:
Status:	Duplicate	Impact on me:	None
Category:	MySQL Server: InnoDB storage engine	Severity:	S2 (Serious)
Version:	5.1	OS:	Any
Assigned to:		CPU Architecture:	Any

Description:
When the following query was executed against an innnodb table containing 1M records:

SELECT `int_unsigned` FROM `table1000000_innodb_int_autoinc`
WHERE ( `pk`  BETWEEN 0 AND 3457679360 )
OR ( `int_unsigned_key`  IN ( 457244672 , 9 , 216 ) )
GROUP BY `pk`
LIMIT 220;

Innodb crashed as follows:

#2  0x000000000063ff3b in handle_segfault (sig=11) at mysqld.cc:2536
#3  <signal handler called>
#4  0x00000000008dab09 in row_sel_field_store_in_mysql_format (dest=0x1 <Address 0x1 out of bounds>, templ=0x7f2fec7170b8, data=0x7f2febe3808f "", len=4)
    at row/row0sel.c:2464
#5  0x00000000008daf8a in row_sel_store_mysql_rec (mysql_rec=0x0, prebuilt=0x7f2fec7160b8, rec=0x7f2febe3807e "\200", offsets=0x7f2fe9d960e0)
    at row/row0sel.c:2670
#6  0x00000000008dd4bb in row_search_for_mysql (buf=0x0, mode=1, prebuilt=0x7f2fec7160b8, match_mode=0, direction=0) at row/row0sel.c:4234
#7  0x0000000000872fb3 in ha_innobase::index_read (this=0x26e7dc8, buf=0x0, key_ptr=0x0, key_len=0, find_flag=HA_READ_AFTER_KEY) at handler/ha_innodb.cc:4410
#8  0x000000000086b329 in ha_innobase::index_first (this=0x26e7dc8, buf=0x0) at handler/ha_innodb.cc:4674
#9  0x0000000000872ca9 in ha_innobase::rnd_next (this=0x26e7dc8, buf=0x0) at handler/ha_innodb.cc:4771
#10 0x0000000000778598 in rr_sequential (info=0x26f8e60) at records.cc:381
#11 0x00000000006c1b6d in join_init_read_record (tab=0x26f8de0) at sql_select.cc:11802
#12 0x00000000006c0ec5 in sub_select (join=0x26e5b38, join_tab=0x26f8de0, end_of_records=false) at sql_select.cc:11130
#13 0x00000000006d23c9 in do_select (join=0x26e5b38, fields=0x7f2fe00676c8, table=0x0, procedure=0x0) at sql_select.cc:10887
#14 0x00000000006e47b0 in JOIN::exec (this=0x26e5b38) at sql_select.cc:2199
#15 0x00000000006df5d3 in mysql_select (thd=0x7f2fe0065738, rref_pointer_array=0x7f2fe0067790, tables=0x26f7570, wild_num=0, fields=@0x7f2fe00676c8,
    conds=0x26f8128, og_num=1, order=0x0, group=0x26f8318, having=0x0, proc_param=0x0, select_options=2147764736, result=0x26f83e8, unit=0x7f2fe0067198,
    select_lex=0x7f2fe00675c0) at sql_select.cc:2386
#16 0x00000000006e4af0 in handle_select (thd=0x7f2fe0065738, lex=0x7f2fe00670f8, result=0x26f83e8, setup_tables_done_option=0) at sql_select.cc:268
#17 0x000000000064f80b in execute_sqlcom_select (thd=0x7f2fe0065738, all_tables=0x26f7570) at sql_parse.cc:5009
#18 0x0000000000651725 in mysql_execute_command (thd=0x7f2fe0065738) at sql_parse.cc:2211
#19 0x000000000065a596 in mysql_parse (thd=0x7f2fe0065738,
    inBuf=0x26f7198 "SELECT `int_unsigned` FROM `table1000000_innodb_int_autoinc` WHERE ( `pk`  BETWEEN 0 AND 3457679360 ) OR ( `int_unsigned_key`  IN ( 457244672 , 9 , 216 ) ) GROUP BY `pk`  LIMIT 220", length=180, found_semicolon=0x7f2fe9d98ee0) at sql_parse.cc:5929
#20 0x000000000065b3c0 in dispatch_command (command=COM_QUERY, thd=0x7f2fe0065738, packet=0x7f2fe0068089 "", packet_length=180) at sql_parse.cc:1216
#21 0x000000000065c7a5 in do_command (thd=0x7f2fe0065738) at sql_parse.cc:857
#22 0x00000000006490ca in handle_one_connection (arg=0x7f2fe0065738) at sql_connect.cc:1115
#23 0x000000315b0073da in start_thread () from /lib64/libpthread.so.0
#24 0x000000315a4e627d in clone () from /lib64/libc.so.6

How to repeat:
Run the query provided against the datadir that will be attached.

Vardir:

http://mysql-systemqa.s3.amazonaws.com/var-bug46004.zip

Can we have exact MySQL version, my.cnf contents and could you
run CHECK TABLE on the tables in the dataset to see if it's generally
corrupted?

Hello, sorry for the missing information.

The server is a debug build from the 5.1-bugteam tree. The server was started with MTR_VERSION=1 perl mysql-test-run.pl --start-and-exit , and does not make use of any my.cnf files.

With respect to the data corruption, I did not do anything that would cause that. Would you agree that a crash would be a valid bug regardless of whether the database was corrupted or not?

regarding the bugteam tree where you reproduce the bug, could you enlighten me 
as to its contents? If it's identical to MySQL 5.1.x or to any recent bzr version
(= 5.1.37) it's one thing. If it's one of the above + some not yet published
bug fixes, it's a different thing. We can only look at problems with published versions, not team trees. 
Regarding the corruption, if the dataset is not corrupted then we already have a the testcase. If it is corrupted, we'd be interested how it got corrupted, not how we fail when the dataset is corrupted. The testcase would then be whatever way you created the corrupted dataset.
So I wonder if you could reproduce this on an official source.
as for the configuration parameters as there's no 100% guarantee your way of starting mysqld results in the same configuration version to version, could you attach for the reference the output of 'mysqladmin variables'?

Not repeatable with mysql-5.1 and with 5.1.36. Appears to be a false alarm of some sort. Thank you and apologies.

probably a duplicate of bug #44810