[MDEV-21495] Conditional jump or move depends on uninitialised value in sel_arg_range_seq_next Created: 2020-01-15  Updated: 2020-05-26  Resolved: 2020-05-26

Status: Closed
Project: MariaDB Server
Component/s: Optimizer
Affects Version/s: 10.1, 10.2, 10.3, 10.4, 10.5
Fix Version/s: 10.5.4, 10.1.46, 10.2.33, 10.3.24, 10.4.14

Type: Bug Priority: Major
Reporter: Elena Stepanova Assignee: Varun Gupta (Inactive)
Resolution: Fixed Votes: 0
Labels: None


 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.



 Comments   
Comment by Oleksandr Byelkin [ 2020-05-13 ]

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

Comment by Varun Gupta (Inactive) [ 2020-05-25 ]

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

Comment by Varun Gupta (Inactive) [ 2020-05-25 ]

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

Comment by Igor Babaev [ 2020-05-25 ]

It's ok to push it 10.1

Generated at Thu Feb 08 09:07:34 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.