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

LP:598247 - partition.test produces valgrind errors in 5.3-based branches

        Details

        • Type: Bug
        • Status: Closed
        • Resolution: Not a Bug
        • Affects Version/s: None
        • Fix Version/s: None
        • Component/s: None
        • Labels:

          Description

          partition.test produces valgrind errors in 5.3-based branches. There is no such failure in 5.2

          worker[1] Using MTR_BUILD_THREAD 301, with reserved ports 13010..13019
          main.partition [ fail ] Found warnings/errors in server log file!
          Test ended at 2010-06-24 23:58:36
          mysqltest: Logging to ''.
          mysqltest: Results saved in ''.
          mysqltest: Connecting to server localhost:13010 (socket /home/psergey/dev2/maria-5.3-subqueries-r12-vg/mysql-test/var/tmp/mysqld.1.sock) as 'root', connection 'default', attempt 0 ...
          mysqltest: ... Connected.
          mysqltest: Start processing test commands from './include/check-warnings.test' ...
          line
          ==5946== Thread 9:
          ==5946== Conditional jump or move depends on uninitialised value(s)
          ==5946== at 0x82F304C: JOIN_CACHE::write_record_data(unsigned char*, bool*) (sql_join_cache.cc:1075)
          ==5946== by 0x82F36B2: JOIN_CACHE::put_record() (sql_join_cache.cc:1234)
          ==5946== by 0x8324E60: sub_select_cache(JOIN*, st_join_table*, bool) (sql_select.cc:12936)
          ==5946== by 0x83247AF: evaluate_join_record(JOIN*, st_join_table*, int) (sql_select.cc:13316)
          ==5946== by 0x8324B0B: sub_select(JOIN*, st_join_table*, bool) (sql_select.cc:13133)
          ==5946== by 0x8332859: do_select(JOIN*, List<Item>, st_table, Procedure*) (sql_select.cc:12680)
          ==5946== by 0x83468AA: JOIN::exec() (sql_select.cc:2201)
          ==5946== by 0x8340DC1: 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:2396)
          ==5946== by 0x8346BDB: handle_select(THD*, st_lex*, select_result*, unsigned long) (sql_select.cc:279)
          ==5946== by 0x82AB34F: execute_sqlcom_select(THD*, TABLE_LIST*) (sql_parse.cc:5133)
          ==5946== by 0x82AD549: mysql_execute_command(THD*) (sql_parse.cc:2318)
          ==5946== by 0x82B70D5: mysql_parse(THD*, char const*, unsigned int, char const**) (sql_parse.cc:6079)
          ==5946== by 0x82B7EB2: dispatch_command(enum_server_command, THD*, char*, unsigned int) (sql_parse.cc:1253)
          ==5946== by 0x82B945E: do_command(THD*) (sql_parse.cc:891)
          ==5946== by 0x82A344B: handle_one_connection (sql_connect.cc:1599)
          ==5946== by 0x406C4FE: start_thread (in /lib/tls/i686/cmov/libpthread-2.9.so)
          ==5946==
          ==5946== Conditional jump or move depends on uninitialised value(s)
          ==5946== at 0x82F249C: JOIN_CACHE::read_record_field(st_cache_field*, bool) (sql_join_cache.cc:1446)
          ==5946== by 0x82F2C26: JOIN_CACHE::read_all_record_fields() (sql_join_cache.cc:1384)
          ==5946== by 0x82F2D41: JOIN_CACHE::get_record() (sql_join_cache.cc:1276)
          ==5946== by 0x82F2392: JOIN_CACHE_BNL::join_matching_records(bool) (sql_join_cache.cc:1856)
          ==5946== by 0x82F065B: JOIN_CACHE::join_records(bool) (sql_join_cache.cc:1665)
          ==5946== by 0x8324D94: sub_select_cache(JOIN*, st_join_table*, bool) (sql_select.cc:12923)
          ==5946== by 0x8324974: sub_select(JOIN*, st_join_table*, bool) (sql_select.cc:13085)
          ==5946== by 0x8332882: do_select(JOIN*, List<Item>, st_table, Procedure*) (sql_select.cc:12682)
          ==5946== by 0x83468AA: JOIN::exec() (sql_select.cc:2201)
          ==5946== by 0x8340DC1: 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:2396)
          ==5946== by 0x8346BDB: handle_select(THD*, st_lex*, select_result*, unsigned long) (sql_select.cc:279)
          ==5946== by 0x82AB34F: execute_sqlcom_select(THD*, TABLE_LIST*) (sql_parse.cc:5133)
          ==5946== by 0x82AD549: mysql_execute_command(THD*) (sql_parse.cc:2318)
          ==5946== by 0x82B70D5: mysql_parse(THD*, char const*, unsigned int, char const**) (sql_parse.cc:6079)
          ==5946== by 0x82B7EB2: dispatch_command(enum_server_command, THD*, char*, unsigned int) (sql_parse.cc:1253)
          ==5946== by 0x82B945E: do_command(THD*) (sql_parse.cc:891)
          ==5946==
          ==5946== Conditional jump or move depends on uninitialised value(s)
          ==5946== at 0x82F249C: JOIN_CACHE::read_record_field(st_cache_field*, bool) (sql_join_cache.cc:1446)
          ==5946== by 0x82F2C26: JOIN_CACHE::read_all_record_fields() (sql_join_cache.cc:1384)
          ==5946== by 0x82F2C6E: JOIN_CACHE::get_record_by_pos(unsigned char*) (sql_join_cache.cc:1308)
          ==5946== by 0x82F0323: JOIN_CACHE::restore_last_record() (sql_join_cache.cc:1614)
          ==5946== by 0x82F0829: JOIN_CACHE::join_records(bool) (sql_join_cache.cc:1737)
          ==5946== by 0x8324D94: sub_select_cache(JOIN*, st_join_table*, bool) (sql_select.cc:12923)
          ==5946== by 0x8324974: sub_select(JOIN*, st_join_table*, bool) (sql_select.cc:13085)
          ==5946== by 0x8332882: do_select(JOIN*, List<Item>, st_table, Procedure*) (sql_select.cc:12682)
          ==5946== by 0x83468AA: JOIN::exec() (sql_select.cc:2201)
          ==5946== by 0x8340DC1: 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:2396)
          ==5946== by 0x8346BDB: handle_select(THD*, st_lex*, select_result*, unsigned long) (sql_select.cc:279)
          ==5946== by 0x82AB34F: execute_sqlcom_select(THD*, TABLE_LIST*) (sql_parse.cc:5133)
          ==5946== by 0x82AD549: mysql_execute_command(THD*) (sql_parse.cc:2318)
          ==5946== by 0x82B70D5: mysql_parse(THD*, char const*, unsigned int, char const**) (sql_parse.cc:6079)
          ==5946== by 0x82B7EB2: dispatch_command(enum_server_command, THD*, char*, unsigned int) (sql_parse.cc:1253)
          ==5946== by 0x82B945E: do_command(THD*) (sql_parse.cc:891)
          ^ Found warnings in /home/psergey/dev2/maria-5.3-subqueries-r12-vg/mysql-test/var/log/mysqld.1.err
          mysqltest: ... Done processing test commands.
          mysqltest: Test has succeeded!
          ok

          • saving '/home/psergey/dev2/maria-5.3-subqueries-r12-vg/mysql-test/var/log/main.partition/' to '/home/psergey/dev2/maria-5.3-subqueries-r12-vg/mysql-test/var/log/main.partition/'
            ------------------------------------------------------------
            The servers were restarted 0 times
            Spent 0.000 of 104 seconds executing testcases
            mysql-test-run: WARNING: Got errors/warnings while running tests, please examine '/home/psergey/dev2/maria-5.3-subqueries-r12-vg/mysql-test/var/log/warnings' for details.

          Failed 1/1 tests, 0.00% were successful.

          Failing test(s): main.partition

          The log files in var/log may give you some hint of what went wrong.

          If you want to report this error, please read first the documentation
          at http://dev.mysql.com/doc/mysql/en/mysql-test-suite.html

          mysql-test-run: *** ERROR: there were failing test cases
          psergey@pslp2:~/dev2/maria-5.3-subqueries-r12-vg/mysql-test$

            Gliffy Diagrams

              Attachments

                Activity

                Ascending order - Click to sort in descending order
                Hide
                Permalink
                psergey Sergei Petrunia added a comment -

                Re: partition.test produces valgrind errors in 5.3-based branches
                The simplest testcase:

                --disable_warnings
                drop table if exists t1, t2;
                --enable_warnings

                CREATE TABLE t1 (
                a INT DEFAULT NULL,
                b DOUBLE DEFAULT NULL,
                c INT DEFAULT NULL,
                KEY idx2(b,a)
                ) engine=myisam PARTITION BY HASH(c) PARTITIONS 3;

                INSERT INTO t1 VALUES (6,8,9);
                INSERT INTO t1 VALUES (6,8,10);

                SELECT 1 FROM t1 JOIN t1 AS t2 USING (a);

                1. FOR UPDATE - is not necessary.

                drop table t1;

                Show
                psergey Sergei Petrunia added a comment - Re: partition.test produces valgrind errors in 5.3-based branches The simplest testcase: --disable_warnings drop table if exists t1, t2; --enable_warnings CREATE TABLE t1 ( a INT DEFAULT NULL, b DOUBLE DEFAULT NULL, c INT DEFAULT NULL, KEY idx2(b,a) ) engine=myisam PARTITION BY HASH(c) PARTITIONS 3; INSERT INTO t1 VALUES (6,8,9); INSERT INTO t1 VALUES (6,8,10); SELECT 1 FROM t1 JOIN t1 AS t2 USING (a); FOR UPDATE - is not necessary. drop table t1;
                Hide
                Permalink
                psergey Sergei Petrunia added a comment -

                Re: partition.test produces valgrind errors in 5.3-based branches
                The EXPLAIN of the query causing the warning:

                MySQL [jun28]> explain SELECT 1 FROM t1 JOIN t1 AS t2 USING (a);
                ----------------------------------------------------------------------------------------------------+

                id select_type table type possible_keys key key_len ref rows Extra

                ----------------------------------------------------------------------------------------------------+

                1 SIMPLE t1 index NULL idx2 14 NULL 2 Using index
                1 SIMPLE t2 index NULL idx2 14 NULL 2 Using where; Using index; Using join buffer

                ----------------------------------------------------------------------------------------------------+
                2 rows in set (0.03 sec)

                Show
                psergey Sergei Petrunia added a comment - Re: partition.test produces valgrind errors in 5.3-based branches The EXPLAIN of the query causing the warning: MySQL [jun28] > explain SELECT 1 FROM t1 JOIN t1 AS t2 USING (a); --- ----------- ----- ----- ------------- ---- ------- ---- ---- --------------------------------------------+ id select_type table type possible_keys key key_len ref rows Extra --- ----------- ----- ----- ------------- ---- ------- ---- ---- --------------------------------------------+ 1 SIMPLE t1 index NULL idx2 14 NULL 2 Using index 1 SIMPLE t2 index NULL idx2 14 NULL 2 Using where; Using index; Using join buffer --- ----------- ----- ----- ------------- ---- ------- ---- ---- --------------------------------------------+ 2 rows in set (0.03 sec)
                Hide
                Permalink
                psergey Sergei Petrunia added a comment -

                Re: partition.test produces valgrind errors in 5.3-based branches
                Upon investigation, discovered the following:

                The failure occurs when trying to read the value of t1.c from join buffer. It
                is wrong that t1.c is present in the join buffer, because

                • it is not really needed by the query
                • EXPLAIN shows "Using index" for table t1 (and that is correct, the
                  executor really uses HA_EXTRA_KEYREAD for table t1), so we don't
                  really have the value of t1.c

                Table t1's data structures are not self-consistent with regards to t1.c:

                (gdb) p this
                $21 = (TABLE * const) 0xa707470
                (gdb) p this->alias
                $22 = 0xa6df300 "t1"
                (gdb) p/x this->read_set->last_word_mask
                $23 = 0xfffffff8
                (gdb) p/x *(this->read_set->last_word_ptr)
                $24 = 0x5
                (gdb) p this->covering_keys
                $25 =

                {map = 1}

                that is, the index idx2 is considered covering, even though it doesn't include
                t1.c which is in the read set.

                Show
                psergey Sergei Petrunia added a comment - Re: partition.test produces valgrind errors in 5.3-based branches Upon investigation, discovered the following: The failure occurs when trying to read the value of t1.c from join buffer. It is wrong that t1.c is present in the join buffer, because it is not really needed by the query EXPLAIN shows "Using index" for table t1 (and that is correct, the executor really uses HA_EXTRA_KEYREAD for table t1), so we don't really have the value of t1.c Table t1's data structures are not self-consistent with regards to t1.c: (gdb) p this $21 = (TABLE * const) 0xa707470 (gdb) p this->alias $22 = 0xa6df300 "t1" (gdb) p/x this->read_set->last_word_mask $23 = 0xfffffff8 (gdb) p/x *(this->read_set->last_word_ptr) $24 = 0x5 (gdb) p this->covering_keys $25 = {map = 1} that is, the index idx2 is considered covering, even though it doesn't include t1.c which is in the read set.
                Hide
                Permalink
                psergey Sergei Petrunia added a comment -

                Re: partition.test produces valgrind errors in 5.3-based branches
                For some reason, lp:~mysql/mysql-server/mysql-trunk/ doesn't produce the valgrind warning, although it has the same problem - "index only" read is used, and a non-indexed column is put into join buffer.

                Show
                psergey Sergei Petrunia added a comment - Re: partition.test produces valgrind errors in 5.3-based branches For some reason, lp:~mysql/mysql-server/mysql-trunk/ doesn't produce the valgrind warning, although it has the same problem - "index only" read is used, and a non-indexed column is put into join buffer.
                Hide
                Permalink
                timour Timour Katchaounov added a comment -

                Re: partition.test produces valgrind errors in 5.3-based branches
                There is no longer a valgrind warning with the latest 5.3 as of 14-06-2011.
                Sergey, could you please re-verify in GDB whether the internal state is
                correct or not. I think the test case should be added to the regression suite.

                Show
                timour Timour Katchaounov added a comment - Re: partition.test produces valgrind errors in 5.3-based branches There is no longer a valgrind warning with the latest 5.3 as of 14-06-2011. Sergey, could you please re-verify in GDB whether the internal state is correct or not. I think the test case should be added to the regression suite.
                Hide
                Permalink
                psergey Sergei Petrunia added a comment -

                Re: partition.test produces valgrind errors in 5.3-based branches
                Checked against revision-id:psergey@askmonty.org-20110615113224-sjcubimc0x1vtzr2. The data structures are still not self-consistent, in the same way as it was mentioned in comment #3.

                Show
                psergey Sergei Petrunia added a comment - Re: partition.test produces valgrind errors in 5.3-based branches Checked against revision-id:psergey@askmonty.org-20110615113224-sjcubimc0x1vtzr2. The data structures are still not self-consistent, in the same way as it was mentioned in comment #3.
                Hide
                Permalink
                psergey Sergei Petrunia added a comment -

                Re: partition.test produces valgrind errors in 5.3-based branches
                The valgrind warning can no longer be repeated. Pushed a testcase.

                Show
                psergey Sergei Petrunia added a comment - Re: partition.test produces valgrind errors in 5.3-based branches The valgrind warning can no longer be repeated. Pushed a testcase.
                Hide
                Permalink
                ratzpo Rasmus Johansson added a comment -

                Launchpad bug id: 598247

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

                  People

                  • Assignee:
                    psergey Sergei Petrunia
                    Reporter:
                    psergey Sergei Petrunia
                  • Votes:
                    0 Vote for this issue
                    Watchers:
                    0 Start watching this issue

                    Dates

                    • Created:
                      Updated:
                      Resolved: