[MDEV-5732] Valgrind warning for index_merge and extended_keys - JIRA

Details

Type: Bug
Status: Closed
Priority: Major
Resolution: Fixed
Affects Version/s: 10.0.9
Fix Version/s: 10.0.9
Component/s: None
Labels:
None

Description

Below is an extract of index_merge_innodb.test which started to cause a valgrind failure after default optimizer_switch was changed to include 'extended_keys=ON':

# Slow test, don't run during staging part
--source include/not_staging.inc
--source include/have_xtradb.inc

let $engine_type= InnoDB;

set @optimizer_switch_save= @@optimizer_switch;
set optimizer_switch='index_merge_sort_intersection=off';

eval SET SESSION STORAGE_ENGINE = $engine_type;

--disable_warnings
drop table if exists t1;
--enable_warnings

# Testcase for BUG#4984
create table t1
(
  RUNID varchar(22),
  SUBMITNR varchar(5),
  ORDERNR char(1),
  PROGRAMM varchar(8),
  TESTID varchar(4),
  UCCHECK char(1),
  ETEXT varchar(80),
  ETEXT_TYPE char(1),
  INFO char(1),
  SEVERITY tinyint(3),
  TADIRFLAG char(1),
  PRIMARY KEY  (RUNID,SUBMITNR,ORDERNR,PROGRAMM,TESTID,UCCHECK),
  KEY `TVERM~KEY`  (PROGRAMM,TESTID,UCCHECK)
) DEFAULT CHARSET=latin1;

update t1 set `ETEXT` = '', `ETEXT_TYPE`='', `INFO`='', `SEVERITY`='', `TADIRFLAG`=''
WHERE
 `RUNID`= '' AND `SUBMITNR`= '' AND `ORDERNR`='' AND `PROGRAMM`='' AND
 `TESTID`='' AND `UCCHECK`='';

drop table t1;
set optimizer_switch= @optimizer_switch_save;

==3333== Thread 16:
==3333== Conditional jump or move depends on uninitialised value(s)
==3333==    at 0x947AF3: is_key_scan_ror(PARAM*, unsigned int, unsigned char) (opt_range.cc:10621)
==3333==    by 0x932DC6: sel_arg_range_seq_next(void*, st_key_multi_range*) (opt_range_mrr.cc:293)
==3333==    by 0x793F6A: handler::multi_range_read_info_const(unsigned int, st_range_seq_if*, void*, unsigned int, unsigned int*, unsigned int*, COST_VECT*) (multi_range_read.cc:71)
==3333==    by 0x79711C: DsMrr_impl::dsmrr_info_const(unsigned int, st_range_seq_if*, void*, unsigned int, unsigned int*, unsigned int*, COST_VECT*) (multi_range_read.cc:1451)
==3333==    by 0xB490AD: ha_innobase::multi_range_read_info_const(unsigned int, st_range_seq_if*, void*, unsigned int, unsigned int*, unsigned int*, COST_VECT*) (ha_innodb.cc:14134)
==3333==    by 0x947690: check_quick_select(PARAM*, unsigned int, bool, SEL_ARG*, bool, unsigned int*, unsigned int*, COST_VECT*) (opt_range.cc:10507)
==3333==    by 0x93FD8C: get_key_scans_params(PARAM*, SEL_TREE*, bool, bool, double) (opt_range.cc:7162)
==3333==    by 0x937454: SQL_SELECT::test_quick_select(THD*, Bitmap<64u>, unsigned long long, unsigned long long, bool, bool) (opt_range.cc:3118)
==3333==    by 0x704042: SQL_SELECT::check_quick(THD*, bool, unsigned long long) (opt_range.h:997)
==3333==    by 0x6FDD12: mysql_update(THD*, TABLE_LIST*, List<Item>&, List<Item>&, Item*, unsigned int, st_order*, unsigned long long, enum_duplicates, bool, unsigned long long*, unsigned long long*) (sql_update.cc:419)
==3333==    by 0x634B2D: mysql_execute_command(THD*) (sql_parse.cc:3053)
==3333==    by 0x63D444: mysql_parse(THD*, char*, unsigned int, Parser_state*) (sql_parse.cc:6101)
==3333==    by 0x62FFB2: dispatch_command(enum_server_command, THD*, char*, unsigned int) (sql_parse.cc:1113)
==3333==    by 0x62F396: do_command(THD*) (sql_parse.cc:819)
==3333==    by 0x752AF6: do_handle_one_connection(THD*) (sql_connect.cc:1266)
==3333==    by 0x752864: handle_one_connection (sql_connect.cc:1181)
^ Found warnings in /run/shm/var_auto_SW5b/log/mysqld.1.err

Gliffy Diagrams

Attachments

Activity

Hide

Permalink

Sergei Petrunia added a comment - 2014-02-25 17:23

The problem occurs in the call to is_key_scan_ror(param=..., keynr=1, nparts=6).

The code in is_key_scan_ror() had some limited awareness about InnoDB's extended keys before the Extended Keys feature has been pushed. Apparently, that code doesn't work with explicitly enabled extended keys.

The table has these indexes:
PRIMARY KEY (RUNID,SUBMITNR,ORDERNR,PROGRAMM,TESTID,UCCHECK),
KEY `TVERM~KEY` (PROGRAMM,TESTID,UCCHECK)

If one takes into account extended keys, TVERM~KEY index really is:

PROGRAMM, TESTID, UCCHECK
RUNID, SUBMITNR, ORDERNR,

and the parameter is nparts=6, which means that the range covers both real key parts and extended key parts.

Show

Sergei Petrunia added a comment - 2014-02-25 17:23 The problem occurs in the call to is_key_scan_ror(param=..., keynr=1, nparts=6). The code in is_key_scan_ror() had some limited awareness about InnoDB's extended keys before the Extended Keys feature has been pushed. Apparently, that code doesn't work with explicitly enabled extended keys. The table has these indexes: PRIMARY KEY (RUNID,SUBMITNR,ORDERNR,PROGRAMM,TESTID,UCCHECK), KEY `TVERM~KEY` (PROGRAMM,TESTID,UCCHECK) If one takes into account extended keys, TVERM~KEY index really is: PROGRAMM, TESTID, UCCHECK RUNID, SUBMITNR, ORDERNR, and the parameter is nparts=6, which means that the range covers both real key parts and extended key parts.

Valgrind warning for index_merge and extended_keys

Details

Description

Gliffy Diagrams

Attachments

Activity

People

Dates

Agile