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

LP:702403 - Sporadic wrong results and valgrind failure in/below mm_* functions

    Details

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

      Description

      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.

        Gliffy Diagrams

          Attachments

            Activity

            Hide
            philipstoev Philip Stoev added a comment -

            Re: Sporadic wrong results and valgrind failure in/below mm_* functions
            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)

            Show
            philipstoev Philip Stoev added a comment - Re: Sporadic wrong results and valgrind failure in/below mm_* functions 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)
            Hide
            philipstoev Philip Stoev added a comment -

            Re: Sporadic wrong results and valgrind failure in/below mm_* functions
            bzr version-info:

            revision-id: igor@askmonty.org-20110129025430-221yzgrb7yap99jt
            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

            Show
            philipstoev Philip Stoev added a comment - Re: Sporadic wrong results and valgrind failure in/below mm_* functions bzr version-info: revision-id: igor@askmonty.org-20110129025430-221yzgrb7yap99jt 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
            Hide
            igor Igor Babaev added a comment -

            Re: Sporadic wrong results and valgrind failure in/below mm_* functions
            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.

            Show
            igor Igor Babaev added a comment - Re: Sporadic wrong results and valgrind failure in/below mm_* functions 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.
            Hide
            ratzpo Rasmus Johansson added a comment -

            Launchpad bug id: 702403

            Show
            ratzpo Rasmus Johansson added a comment - Launchpad bug id: 702403

              People

              • Assignee:
                igor Igor Babaev
                Reporter:
                philipstoev Philip Stoev
              • Votes:
                0 Vote for this issue
                Watchers:
                0 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: