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

Conditional jump or move depends on uninitialised value in sel_arg_range_seq_next

Details

    Description

      10.4 valgrind 2d4b6571

      $ perl ./mtr --valgrind main.subselect_mat_cost
       
      main.subselect_mat_cost                  [ fail ]  Found warnings/errors in server log file!
              Test ended at 2020-01-15 18:46:14
      line
      ==7420== Thread 6:
      ==7420== Conditional jump or move depends on uninitialised value(s)
      ==7420==    at 0xDF628B: sel_arg_range_seq_next(void*, st_key_multi_range*) (opt_range_mrr.cc:342)
      ==7420==    by 0xDFC8C0: records_in_column_ranges(PARAM*, unsigned int, SEL_ARG*) (opt_range.cc:3189)
      ==7420==    by 0xDFD50B: calculate_cond_selectivity_for_table(THD*, TABLE*, Item**) (opt_range.cc:3458)
      ==7420==    by 0x961CF5: make_join_statistics(JOIN*, List<TABLE_LIST>&, st_dynamic_array*) (sql_select.cc:5435)
      ==7420==    by 0x9561E1: JOIN::optimize_inner() (sql_select.cc:2235)
      ==7420==    by 0x953B97: JOIN::optimize() (sql_select.cc:1598)
      ==7420==    by 0x8D68E3: st_select_lex::optimize_unflattened_subqueries(bool) (sql_lex.cc:4187)
      ==7420==    by 0xAFFFDF: JOIN::optimize_unflattened_subqueries() (opt_subselect.cc:5512)
      ==7420==    by 0x958389: JOIN::optimize_stage2() (sql_select.cc:2797)
      ==7420==    by 0x9562DF: JOIN::optimize_inner() (sql_select.cc:2261)
      ==7420==    by 0x953B97: JOIN::optimize() (sql_select.cc:1598)
      ==7420==    by 0x95F023: mysql_select(THD*, 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*) (sql_select.cc:4633)
      ==7420==    by 0x99C58B: mysql_explain_union(THD*, st_select_lex_unit*, select_result*) (sql_select.cc:26815)
      ==7420==    by 0x914426: execute_sqlcom_select(THD*, TABLE_LIST*) (sql_parse.cc:6299)
      ==7420==    by 0x909E02: mysql_execute_command(THD*) (sql_parse.cc:3899)
      ==7420==    by 0x918962: mysql_parse(THD*, char*, unsigned int, Parser_state*, bool, bool) (sql_parse.cc:7901)
      

      Reproducible with 10.4, 10.5.
      Also with innodb.innodb-index-online.

      Attachments

        Activity

          main.innodb_icp main.select_pkeycache main.column_compression_parts main.partition (at least in 10.5)

          sanja Oleksandr Byelkin added a comment - main.innodb_icp main.select_pkeycache main.column_compression_parts main.partition (at least in 10.5)

          A simple test case demonstrating the variable is initialized.

          --source include/have_sequence.inc
          CREATE TABLE t1(a INT, b INT);
          INSERT INTO t1 SELECT seq, seq from seq_1_to_100;
          set optimizer_use_condition_selectivity=4;
          set use_stat_tables='preferably';
          ANALYZE TABLE t1 PERSISTENT FOR ALL;
          SELECT * from t1 WHERE a = 5 and b=5;
          drop table t1;
          

          Somehow i don't see the problem in 10.1 or 10.2, but looks the problem is there too

          varun Varun Gupta (Inactive) added a comment - A simple test case demonstrating the variable is initialized. --source include/have_sequence.inc CREATE TABLE t1(a INT , b INT ); INSERT INTO t1 SELECT seq, seq from seq_1_to_100; set optimizer_use_condition_selectivity=4; set use_stat_tables= 'preferably' ; ANALYZE TABLE t1 PERSISTENT FOR ALL ; SELECT * from t1 WHERE a = 5 and b=5; drop table t1; Somehow i don't see the problem in 10.1 or 10.2, but looks the problem is there too

          Debugging I put a breakpoint here

          (lldb) bt
          * thread #2, stop reason = step over
            * frame #0: 0x00000001007b57f6 mysqld`calculate_cond_selectivity_for_table(thd=0x000062b00005b288, table=0x0000620000035108, cond=0x000062b000065168) at opt_range.cc:3447:53
              frame #1: 0x0000000100ebc3db mysqld`make_join_statistics(join=0x000062b000064d58, tables_list=0x000062b0000625c8, keyuse_array=0x000062b000065048) at sql_select.cc:5460:13
              frame #2: 0x0000000100ea2c5f mysqld`JOIN::optimize_inner(this=0x000062b000064d58) at sql_select.cc:2260:7
              frame #3: 0x0000000100e8d3e4 mysqld`JOIN::optimize(this=0x000062b000064d58) at sql_select.cc:1606:10
              frame #4: 0x0000000100e6e2b4 mysqld`mysql_select(thd=0x000062b00005b288, tables=0x000062b0000629b8, fields=0x000062b0000624d8, conds=0x000062b000063968, og_num=0, order=0x0000000000000000, group=0x0000000000000000, having=0x0000000000000000, proc_param=0x0000000000000000, select_options=2147748612, result=0x000062b000064478, unit=0x000062b00005f2c8, select_lex=0x000062b000062388) at sql_select.cc:4655:19
          

          (lldb) p param.max_key_parts
          (uint) $1 = 55299413
          

          I see that max_key_parts is not initialised here and then we use max_key_parts when we walk over the ranges
          Inside the function sel_arg_range_seq_next we have

            seq->param->range_count++;
            seq->param->max_key_parts= MY_MAX(seq->param->max_key_parts, max_key_parts);
          

          and this is where we access the uninitialised value for max_key_parts.

          The fix would be to initialize max_key_parts in sel_arg_range_seq_init

          varun Varun Gupta (Inactive) added a comment - Debugging I put a breakpoint here (lldb) bt * thread #2, stop reason = step over * frame #0: 0x00000001007b57f6 mysqld`calculate_cond_selectivity_for_table(thd=0x000062b00005b288, table=0x0000620000035108, cond=0x000062b000065168) at opt_range.cc:3447:53 frame #1: 0x0000000100ebc3db mysqld`make_join_statistics(join=0x000062b000064d58, tables_list=0x000062b0000625c8, keyuse_array=0x000062b000065048) at sql_select.cc:5460:13 frame #2: 0x0000000100ea2c5f mysqld`JOIN::optimize_inner(this=0x000062b000064d58) at sql_select.cc:2260:7 frame #3: 0x0000000100e8d3e4 mysqld`JOIN::optimize(this=0x000062b000064d58) at sql_select.cc:1606:10 frame #4: 0x0000000100e6e2b4 mysqld`mysql_select(thd=0x000062b00005b288, tables=0x000062b0000629b8, fields=0x000062b0000624d8, conds=0x000062b000063968, og_num=0, order=0x0000000000000000, group=0x0000000000000000, having=0x0000000000000000, proc_param=0x0000000000000000, select_options=2147748612, result=0x000062b000064478, unit=0x000062b00005f2c8, select_lex=0x000062b000062388) at sql_select.cc:4655:19 (lldb) p param.max_key_parts (uint) $1 = 55299413 I see that max_key_parts is not initialised here and then we use max_key_parts when we walk over the ranges Inside the function sel_arg_range_seq_next we have seq->param->range_count++; seq->param->max_key_parts= MY_MAX(seq->param->max_key_parts, max_key_parts); and this is where we access the uninitialised value for max_key_parts. The fix would be to initialize max_key_parts in sel_arg_range_seq_init
          igor Igor Babaev added a comment -

          It's ok to push it 10.1

          igor Igor Babaev added a comment - It's ok to push it 10.1

          People

            varun Varun Gupta (Inactive)
            elenst Elena Stepanova
            Votes:
            0 Vote for this issue
            Watchers:
            4 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.