Sporadic wrong results and valgrind failure in/below mm_* functions

[Philip Stoev]

The RQG command line below reports queries for which using two different plans returns different results, plus a valgrind failure. Unfortunately, it is not possible to reproduce either the different results nor the valgrind failure outside of the RQG.

Valgrind failure:

==31917== Conditional jump or move depends on uninitialised value(s)
==31917== at 0x83B9EBE: sel_trees_must_be_ored(RANGE_OPT_PARAM*, SEL_TREE*, SEL_TREE*, Bitmap<64u>) (opt_range.cc:8132)
==31917== by 0x83BA3AB: tree_or(RANGE_OPT_PARAM*, SEL_TREE*, SEL_TREE*) (opt_range.cc:8327)
==31917== by 0x83B75FB: get_mm_tree(RANGE_OPT_PARAM*, Item*) (opt_range.cc:7165)
==31917== by 0x83B7473: get_mm_tree(RANGE_OPT_PARAM*, Item*) (opt_range.cc:7145)
==31917== by 0x83AEB98: SQL_SELECT::test_quick_select(THD*, Bitmap<64u>, unsigned long long, unsigned long long, bool, bool) (opt_range.cc:3025)
==31917== by 0x831D5BC: make_join_select(JOIN*, SQL_SELECT*, Item*) (sql_select.cc:7070)
==31917== by 0x830BD02: JOIN::optimize() (sql_select.cc:1059)
==31917== by 0x83110F8: mysql_select(THD*, Item***, 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:2607)
==31917== by 0x833B2C7: mysql_explain_union(THD*, st_select_lex_unit*, select_result*) (sql_select.cc:19286)
==31917== by 0x82A4661: execute_sqlcom_select(THD*, TABLE_LIST*) (sql_parse.cc:5049)
==31917== by 0x829B1FA: mysql_execute_command(THD*) (sql_parse.cc:2234)
==31917== by 0x82A6D7D: mysql_parse(THD*, char*, unsigned int, char const**) (sql_parse.cc:6077)
==31917== by 0x8298CE3: dispatch_command(enum_server_command, THD*, char*, unsigned int) (sql_parse.cc:1210)
==31917== by 0x829814D: do_command(THD*) (sql_parse.cc:903)
==31917== by 0x8295229: handle_one_connection (sql_connect.cc:1154)
==31917== by 0x821918: start_thread (in /lib/libpthread-2.12.1.so)

RQG command line:

 perl runall.pl --basedir=/home/philips/bzr/maria-5.3 --seed=1294914836 --filter=conf/optimizer/join_buffer.ff --validator=Transformer --mysqld=--optimizer_switch=outer_join_with_cache=on --engine=Aria --mysqld=--join_cache_level=8 --grammar=conf/optimizer/optimizer_no_subquery.yy --threads=2 --duration=900 --queries=1M --threads=1 --rows=10 --mysqld=--optimizer_switch='join_cache_bka=off' --valgrind

To reproduce, run the RQG command line above and monitor mysql-test/var/log/master.err for valgrind warnings.

[Philip Stoev (philip-stoev)]

Test case. This crashes and produces a valgrind warning only in maria-5.3-mwl128. maria-5.3 does not appear to be affected, however since EXPLAIN also crashes, it is not possible to determine if the two trees use the same query plan.

--source include/have_innodb.inc
CREATE TABLE t1 ( f3 int(11)) ;
CREATE TABLE t2 ( f1 int(11), f2 int(11), PRIMARY KEY (f1), KEY (f2)) ENGINE=InnoDB;
INSERT IGNORE INTO t2 VALUES (1,2);

CREATE OR REPLACE VIEW v1 AS SELECT * FROM t1;

SELECT *
FROM t2 AS alias1
JOIN t2 AS alias2 ON alias1.f2 = alias2.f1
JOIN v1 ON alias2.f1 = v1.f3
WHERE v1.f3 BETWEEN 2 AND 5 AND alias1.f2 IN ( 1 );

valgrind warning:

==19181== Invalid read of size 4
==19181== at 0x83AAA5A: get_full_func_mm_tree(RANGE_OPT_PARAM*, Item_func*, Item_field*, Item*, bool) (opt_range.cc:7111)
==19181== by 0x83AB23C: get_mm_tree(RANGE_OPT_PARAM*, Item*) (opt_range.cc:7216)
==19181== by 0x83AAC6A: get_mm_tree(RANGE_OPT_PARAM*, Item*) (opt_range.cc:7145)
==19181== by 0x83A2F72: SQL_SELECT::test_quick_select(THD*, Bitmap<64u>, unsigned long long, unsigned long long, bool, bool) (opt_range.cc:3025)
==19181== by 0x830ABDA: get_quick_record_count(THD*, SQL_SELECT*, st_table*, Bitmap<64u> const*, unsigned long long) (sql_select.cc:2746)
==19181== by 0x830C74C: make_join_statistics(JOIN*, TABLE_LIST*, Item*, st_dynamic_array*) (sql_select.cc:3203)
==19181== by 0x8304E98: JOIN::optimize() (sql_select.cc:954)
==19181== by 0x830A803: mysql_select(THD*, Item***, TABLE_LIST*, unsigned int, List<Item>&, Item*, unsigned int, st_order*, st_order*, Item*, st_order*, u$
==19181== by 0x8303130: handle_select(THD*, st_lex*, select_result*, unsigned long) (sql_select.cc:282)
==19181== by 0x82A0C9B: execute_sqlcom_select(THD*, TABLE_LIST*) (sql_parse.cc:5070)
==19181== by 0x8297CAA: mysql_execute_command(THD*) (sql_parse.cc:2234)
==19181== by 0x82A3233: mysql_parse(THD*, char*, unsigned int, char const**) (sql_parse.cc:6077)
==19181== by 0x8295942: dispatch_command(enum_server_command, THD*, char*, unsigned int) (sql_parse.cc:1210)
==19181== by 0x8294DEF: do_command(THD*) (sql_parse.cc:903)
==19181== by 0x8291ECD: handle_one_connection (sql_connect.cc:1154)
==19181== by 0x821918: start_thread (in /lib/libpthread-2.12.1.so)

[Philip Stoev (philip-stoev)]

bzr version-info:

revision-id: <email address hidden>
date: 2011-01-28 18:54:30 -0800
build-date: 2011-02-02 15:33:26 +0200
revno: 2897
branch-nick: maria-5.3-mwl128

[Igor Babaev (igorb-seattle)]

  The bug cannot be reproduced with the reported test case for the main
  5.3 tree because the backported fix for bug 59696 masks the
  problem that causes the crash in the mentioned test case. It's not
  clear weather this fix masks this problem in all possible cases.

  Anyway the patch for bug 698882 introduced some inconsistent data
  structures that could contain indirect references to deleted object.
  It happened when two Item_equal objects were merged and the Item_field
  list of the second object was joined to such list of the first object.
  This operation required adjustment of the backward pointers in
  Item fields from the joined list. However the adjustment was missing
  and this caused crashes in the tree for mwl#128.

  That's why I decided to apply the fix to 5.3 too.