Uploaded image for project: 'MariaDB Server'
  1. MariaDB Server
  2. MDEV-5732

Valgrind warning for index_merge and extended_keys

Details

    • Bug
    • Status: Closed (View Workflow)
    • Major
    • Resolution: Fixed
    • 10.0.9
    • 10.0.9
    • None
    • 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

      Attachments

        Activity

          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.

          psergei Sergei Petrunia added a comment - 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.

          People

            psergei Sergei Petrunia
            psergei Sergei Petrunia
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved:

              Git Integration

                Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.