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

main.ctype_cp932 fails in buildbot on a valgrind build

Details

    Description

      http://buildbot.askmonty.org/buildbot/builders/work-amd64-valgrind/builds/6310/steps/test/logs/stdio

      main.ctype_cp932                         w4 [ fail ]  Found warnings/errors in server log file!
      		 
              Test ended at 2014-11-11 06:38:00
      		 
      line
      		 
      ==19887== Thread 4:
      		 
      ==19887== Conditional jump or move depends on uninitialised value(s)
      		 
      ==19887==    at 0xE3EAB6: my_wildcmp_mb_bin_impl (ctype-mb.c:1195)
      		 
      ==19887==    by 0xE3EB31: my_wildcmp_mb_bin (ctype-mb.c:1208)
      		 
      ==19887==    by 0x7D3F73: Item_func_like::val_int() (item_cmpfunc.cc:4890)
      		 
      ==19887==    by 0x80474C: eval_const_cond(Item*) (item_func.cc:79)
      		 
      ==19887==    by 0x63A516: internal_remove_eq_conds(THD*, Item*, Item::cond_result*) (sql_select.cc:14982)
      		 
      ==19887==    by 0x63A724: remove_eq_conds(THD*, Item*, Item::cond_result*) (sql_select.cc:15074)
      		 
      ==19887==    by 0x64567B: make_join_statistics(JOIN*, List<TABLE_LIST>&, Item*, st_dynamic_array*) (sql_select.cc:3839)
      		 
      ==19887==    by 0x646363: JOIN::optimize_inner() (sql_select.cc:1339)
      		 
      ==19887==    by 0x647FC2: JOIN::optimize() (sql_select.cc:1024)
      		 
      ==19887==    by 0x64B981: 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:3294)
      		 
      ==19887==    by 0x64C8EB: handle_select(THD*, LEX*, select_result*, unsigned long) (sql_select.cc:373)
      		 
      ==19887==    by 0x5E370C: execute_sqlcom_select(THD*, TABLE_LIST*) (sql_parse.cc:5261)
      		 
      ==19887==    by 0x5EAFF4: mysql_execute_command(THD*) (sql_parse.cc:2545)
      		 
      ==19887==    by 0x5EDB19: mysql_parse(THD*, char*, unsigned int, Parser_state*) (sql_parse.cc:6407)
      		 
      ==19887==    by 0x5EF54B: dispatch_command(enum_server_command, THD*, char*, unsigned int) (sql_parse.cc:1299)
      		 
      ==19887==    by 0x5F0D31: do_command(THD*) (sql_parse.cc:996)
      		 
      ^ Found warnings in /dev/shm/var_auto_xTWj/4/log/mysqld.1.err

      Attachments

        Issue Links

          blocks

          Task - A task that needs to be done. MDEV-7069 Fix buildbot failures in main server trees

          • Major - Major loss of function.
          • Closed

          Activity

            Ascending order - Click to sort in descending order
            psergei Sergei Petrunia added a comment -

            When I run the test on its own, I get a different failure:

            worker[1] Using MTR_BUILD_THREAD 306, with reserved ports 16120..16139
            		 
            main.ctype_cp932                         [ fail ]  Found warnings/errors in server log file!
            		 
                    Test ended at 2014-11-12 15:52:54
            		 
            line
            		 
            ==30146== Thread 4:
            		 
            ==30146== Source and destination overlap in memcpy(0xc8742f8, 0xc8742f8, 20)
            		 
            ==30146==    at 0x4C2810E: memcpy (mc_replace_strmem.c:878)
            		 
            ==30146==    by 0x6C6658: JOIN::exec_inner() (sql_select.cc:2892)
            		 
            ==30146==    by 0x6C3A42: JOIN::exec() (sql_select.cc:2370)
            		 
            ==30146==    by 0x6C3F08: 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:3308)
            		 
            ==30146==    by 0x6C763C: handle_select(THD*, LEX*, select_result*, unsigned long) (sql_select.cc:373)
            		 
            ==30146==    by 0x65683D: execute_sqlcom_select(THD*, TABLE_LIST*) (sql_parse.cc:5261)
            		 
            ==30146==    by 0x658C65: mysql_execute_command(THD*) (sql_parse.cc:2545)
            		 
            ==30146==    by 0x6607E7: mysql_parse(THD*, char*, unsigned int, Parser_state*) (sql_parse.cc:6407)
            		 
            ==30146==    by 0x661351: dispatch_command(enum_server_command, THD*, char*, unsigned int) (sql_parse.cc:1299)
            		 
            ==30146==    by 0x662BF9: do_command(THD*) (sql_parse.cc:996)
            		 
            ==30146==    by 0x76E5DA: do_handle_one_connection(THD*) (sql_connect.cc:1379)
            		 
            ==30146==    by 0x76E6CB: handle_one_connection (sql_connect.cc:1293)
            		 
            ==30146==    by 0xA2DB2D: pfs_spawn_thread (pfs.cc:1860)
            		 
            ==30146==    by 0x4E3506F: start_thread (in /lib64/libpthread-2.9.so)
            		 
            ==30146==    by 0x62F913C: clone (in /lib64/libc-2.9.so)
            		 
            ==30146== Source and destination overlap in memcpy(0xc874340, 0xc874340, 20)
            		 
            ==30146==    at 0x4C2810E: memcpy (mc_replace_strmem.c:878)
            		 
            ==30146==    by 0x6C667E: JOIN::exec_inner() (sql_select.cc:2893)
            		 
            ==30146==    by 0x6C3A42: JOIN::exec() (sql_select.cc:2370)
            		 
            ==30146==    by 0x6C3F08: 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:3308)
            		 
            ==30146==    by 0x6C763C: handle_select(THD*, LEX*, select_result*, unsigned long) (sql_select.cc:373)
            		 
            ==30146==    by 0x65683D: execute_sqlcom_select(THD*, TABLE_LIST*) (sql_parse.cc:5261)
            		 
            ==30146==    by 0x658C65: mysql_execute_command(THD*) (sql_parse.cc:2545)
            		 
            ==30146==    by 0x6607E7: mysql_parse(THD*, char*, unsigned int, Parser_state*) (sql_parse.cc:6407)
            		 
            ==30146==    by 0x661351: dispatch_command(enum_server_command, THD*, char*, unsigned int) (sql_parse.cc:1299)
            		 
            ==30146==    by 0x662BF9: do_command(THD*) (sql_parse.cc:996)
            		 
            ==30146==    by 0x76E5DA: do_handle_one_connection(THD*) (sql_connect.cc:1379)
            		 
            ==30146==    by 0x76E6CB: handle_one_connection (sql_connect.cc:1293)
            		 
            ==30146==    by 0xA2DB2D: pfs_spawn_thread (pfs.cc:1860)
            		 
            ==30146==    by 0x4E3506F: start_thread (in /lib64/libpthread-2.9.so)
            		 
            ==30146==    by 0x62F913C: clone (in /lib64/libc-2.9.so)
            		 
            ^ Found warnings in /home/psergey/dev2/10.0-vg/mysql-test/var/log/mysqld.1.err
            		 
            ok

            psergei Sergei Petrunia added a comment - When I run the test on its own, I get a different failure: worker[1] Using MTR_BUILD_THREAD 306, with reserved ports 16120..16139 main.ctype_cp932 [ fail ] Found warnings/errors in server log file! Test ended at 2014-11-12 15:52:54 line ==30146== Thread 4: ==30146== Source and destination overlap in memcpy(0xc8742f8, 0xc8742f8, 20) ==30146== at 0x4C2810E: memcpy (mc_replace_strmem.c:878) ==30146== by 0x6C6658: JOIN::exec_inner() (sql_select.cc:2892) ==30146== by 0x6C3A42: JOIN::exec() (sql_select.cc:2370) ==30146== by 0x6C3F08: 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:3308) ==30146== by 0x6C763C: handle_select(THD*, LEX*, select_result*, unsigned long) (sql_select.cc:373) ==30146== by 0x65683D: execute_sqlcom_select(THD*, TABLE_LIST*) (sql_parse.cc:5261) ==30146== by 0x658C65: mysql_execute_command(THD*) (sql_parse.cc:2545) ==30146== by 0x6607E7: mysql_parse(THD*, char*, unsigned int, Parser_state*) (sql_parse.cc:6407) ==30146== by 0x661351: dispatch_command(enum_server_command, THD*, char*, unsigned int) (sql_parse.cc:1299) ==30146== by 0x662BF9: do_command(THD*) (sql_parse.cc:996) ==30146== by 0x76E5DA: do_handle_one_connection(THD*) (sql_connect.cc:1379) ==30146== by 0x76E6CB: handle_one_connection (sql_connect.cc:1293) ==30146== by 0xA2DB2D: pfs_spawn_thread (pfs.cc:1860) ==30146== by 0x4E3506F: start_thread (in /lib64/libpthread-2.9.so) ==30146== by 0x62F913C: clone (in /lib64/libc-2.9.so) ==30146== Source and destination overlap in memcpy(0xc874340, 0xc874340, 20) ==30146== at 0x4C2810E: memcpy (mc_replace_strmem.c:878) ==30146== by 0x6C667E: JOIN::exec_inner() (sql_select.cc:2893) ==30146== by 0x6C3A42: JOIN::exec() (sql_select.cc:2370) ==30146== by 0x6C3F08: 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:3308) ==30146== by 0x6C763C: handle_select(THD*, LEX*, select_result*, unsigned long) (sql_select.cc:373) ==30146== by 0x65683D: execute_sqlcom_select(THD*, TABLE_LIST*) (sql_parse.cc:5261) ==30146== by 0x658C65: mysql_execute_command(THD*) (sql_parse.cc:2545) ==30146== by 0x6607E7: mysql_parse(THD*, char*, unsigned int, Parser_state*) (sql_parse.cc:6407) ==30146== by 0x661351: dispatch_command(enum_server_command, THD*, char*, unsigned int) (sql_parse.cc:1299) ==30146== by 0x662BF9: do_command(THD*) (sql_parse.cc:996) ==30146== by 0x76E5DA: do_handle_one_connection(THD*) (sql_connect.cc:1379) ==30146== by 0x76E6CB: handle_one_connection (sql_connect.cc:1293) ==30146== by 0xA2DB2D: pfs_spawn_thread (pfs.cc:1860) ==30146== by 0x4E3506F: start_thread (in /lib64/libpthread-2.9.so) ==30146== by 0x62F913C: clone (in /lib64/libc-2.9.so) ^ Found warnings in /home/psergey/dev2/10.0-vg/mysql-test/var/log/mysqld.1.err ok
            psergei Sergei Petrunia added a comment -

            Hmm.. after re-compling the tree exactly like the buildbot does, this new failure is gone, and I get a failure just like in the report.

            psergei Sergei Petrunia added a comment - Hmm.. after re-compling the tree exactly like the buildbot does, this new failure is gone, and I get a failure just like in the report.
            psergei Sergei Petrunia added a comment -

            The query that causes the error:

            query: SET character_set_results= 'utf8'
            		 
            query: CREATE TABLE t1 (a VARCHAR(10) COLLATE cp932_bin)
            		 
            query: INSERT INTO t1 VALUES('ｶｶ')
            		 
            query: SELECT * FROM t1 WHERE a LIKE '%ｶ'
            		 
            ==11249== Thread 4:
            		 
            ==11249== Conditional jump or move depends on uninitialised value(s)
            		 
            ==11249==    at 0xFC939C: my_wildcmp_mb_bin_impl (ctype-mb.c:1195)
            		 
            ==11249==    by 0xFC9431: my_wildcmp_mb_bin (ctype-mb.c:1208)
            		 
            ==11249==    by 0x89147B: Item_func_like::val_int() (item_cmpfunc.cc:4890)
            		 
            ==11249==    by 0x8BC8E3: eval_const_cond(Item*) (item_func.cc:79)
            		 
            ==11249==    by 0x6A7F55: internal_remove_eq_conds(THD*, Item*, Item::cond_result*) (sql_select.cc:14982)
            		 
            ==11249==    by 0x6A82D3: remove_eq_conds(THD*, Item*, Item::cond_result*) (sql_select.cc:15074)
            		 
            ==11249==    by 0x6C47E1: make_join_statistics(JOIN*, List<TABLE_LIST>&, Item*, st_dynamic_array*) (sql_select.cc:3839)
            		 
            ==11249==    by 0x6C69E1: JOIN::optimize_inner() (sql_select.cc:1339)
            		 
            ==11249==    by 0x6C8CE0: JOIN::optimize() (sql_select.cc:1024)
            		 
            ==11249==    by 0x6C9294: 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:3294)
            		 
            ==11249==    by 0x6CCB07: handle_select(THD*, LEX*, select_result*, unsigned long) (sql_select.cc:373)
            		 
            ==11249==    by 0x65A96B: execute_sqlcom_select(THD*, TABLE_LIST*) (sql_parse.cc:5262)
            		 
            ==11249==    by 0x65CD93: mysql_execute_command(THD*) (sql_parse.cc:2546)
            		 
            ==11249==    by 0x66491F: mysql_parse(THD*, char*, unsigned int, Parser_state*) (sql_parse.cc:6408)
            		 
            ==11249==    by 0x6654B3: dispatch_command(enum_server_command, THD*, char*, unsigned int) (sql_parse.cc:1300)
            		 
            ==11249==    by 0x666D5B: do_command(THD*) (sql_parse.cc:996)

            psergei Sergei Petrunia added a comment - The query that causes the error: query: SET character_set_results= 'utf8' query: CREATE TABLE t1 (a VARCHAR(10) COLLATE cp932_bin) query: INSERT INTO t1 VALUES('ｶｶ') query: SELECT * FROM t1 WHERE a LIKE '%ｶ' ==11249== Thread 4: ==11249== Conditional jump or move depends on uninitialised value(s) ==11249== at 0xFC939C: my_wildcmp_mb_bin_impl (ctype-mb.c:1195) ==11249== by 0xFC9431: my_wildcmp_mb_bin (ctype-mb.c:1208) ==11249== by 0x89147B: Item_func_like::val_int() (item_cmpfunc.cc:4890) ==11249== by 0x8BC8E3: eval_const_cond(Item*) (item_func.cc:79) ==11249== by 0x6A7F55: internal_remove_eq_conds(THD*, Item*, Item::cond_result*) (sql_select.cc:14982) ==11249== by 0x6A82D3: remove_eq_conds(THD*, Item*, Item::cond_result*) (sql_select.cc:15074) ==11249== by 0x6C47E1: make_join_statistics(JOIN*, List<TABLE_LIST>&, Item*, st_dynamic_array*) (sql_select.cc:3839) ==11249== by 0x6C69E1: JOIN::optimize_inner() (sql_select.cc:1339) ==11249== by 0x6C8CE0: JOIN::optimize() (sql_select.cc:1024) ==11249== by 0x6C9294: 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:3294) ==11249== by 0x6CCB07: handle_select(THD*, LEX*, select_result*, unsigned long) (sql_select.cc:373) ==11249== by 0x65A96B: execute_sqlcom_select(THD*, TABLE_LIST*) (sql_parse.cc:5262) ==11249== by 0x65CD93: mysql_execute_command(THD*) (sql_parse.cc:2546) ==11249== by 0x66491F: mysql_parse(THD*, char*, unsigned int, Parser_state*) (sql_parse.cc:6408) ==11249== by 0x6654B3: dispatch_command(enum_server_command, THD*, char*, unsigned int) (sql_parse.cc:1300) ==11249== by 0x666D5B: do_command(THD*) (sql_parse.cc:996)
            psergei Sergei Petrunia added a comment -

            The testcase that fails was added by this cset:

            revno: 4443 [merge]
            		 
            committer: Sergei Golubchik <sergii@pisem.net>
            		 
            branch nick: 10.0
            		 
            timestamp: Sat 2014-10-11 12:52:55 +0200
            		 
            message:
            		 
              merge

            psergei Sergei Petrunia added a comment - The testcase that fails was added by this cset: revno: 4443 [merge] committer: Sergei Golubchik <sergii@pisem.net> branch nick: 10.0 timestamp: Sat 2014-10-11 12:52:55 +0200 message: merge
            psergei Sergei Petrunia added a comment -

            Ok, so we are running this query:

            SELECT * FROM t1 WHERE a LIKE '%ｶ'

            and in my_wildcmp_mb_bin_impl we reach this code:

            	{
            		 
            	  int tmp=my_wildcmp_mb_bin_impl(cs,str,str_end,
            		 
                                                     wildstr,wildend,escape,
            		 
                                                     w_one,w_many, recurse_level+1);
            		 
            	  if (tmp <= 0)
            		 
            	    return (tmp);
            		 
            	}
            		 
                  } while (str != str_end && wildstr[0] != w_many);

            on the last line we have wildstr == wildend, but we still access wildstr[0], the byte beyond the end of the patter. In MariaDB-10.0 this causes a valgrind failure.

            In mysql-5.5, the code inside my_wildcmp_mb_bin_impl executes in exactly the same way. However, the pattern string is zero-terminated and we dont get the valgrind failure.

            I guess this could be fixed by either
            1. Changing the calling convention of my_wildcmp_mb_bin_impl() to imply that the pattern string is null-terminated (let Item_func_like::val_int() call c_ptr_safe() on the pattern)

            2. Changing the condition 

                    } while (str != str_end && wildstr[0] != w_many);

            to not access wildstr[0] when wildstr==wildstr_end.

            I am not sure which is better.

            psergei Sergei Petrunia added a comment - Ok, so we are running this query: SELECT * FROM t1 WHERE a LIKE '%ｶ' and in my_wildcmp_mb_bin_impl we reach this code: { int tmp=my_wildcmp_mb_bin_impl(cs,str,str_end, wildstr,wildend,escape, w_one,w_many, recurse_level+1); if (tmp <= 0) return (tmp); } } while (str != str_end && wildstr[0] != w_many); on the last line we have wildstr == wildend, but we still access wildstr [0] , the byte beyond the end of the patter. In MariaDB-10.0 this causes a valgrind failure. In mysql-5.5, the code inside my_wildcmp_mb_bin_impl executes in exactly the same way. However, the pattern string is zero-terminated and we dont get the valgrind failure. I guess this could be fixed by either 1. Changing the calling convention of my_wildcmp_mb_bin_impl() to imply that the pattern string is null-terminated (let Item_func_like::val_int() call c_ptr_safe() on the pattern) 2. Changing the condition } while (str != str_end && wildstr[0] != w_many); to not access wildstr [0] when wildstr==wildstr_end. I am not sure which is better.
            psergei Sergei Petrunia added a comment -

            bar, this is a charset issue. Could you take over please?

            psergei Sergei Petrunia added a comment - bar , this is a charset issue. Could you take over please?
            bar Alexander Barkov added a comment -

            The problem is also repeatable with ascii characters in a cp932_bin column:

            SET names utf8;
            		 
            DROP TABLE IF EXISTS t1;
            		 
            CREATE TABLE t1 (a VARCHAR(10) COLLATE cp932_bin);
            		 
            INSERT INTO t1 VALUES('aa');
            		 
            SELECT * FROM t1 WHERE a LIKE '%a';

            and with the default collation for cp932:

            SET names utf8;
            		 
            DROP TABLE IF EXISTS t1;
            		 
            CREATE TABLE t1 (a VARCHAR(10) CHARACTER SET cp932);
            		 
            INSERT INTO t1 VALUES('aa');
            		 
            SELECT * FROM t1 WHERE a LIKE '%a';

            bar Alexander Barkov added a comment - The problem is also repeatable with ascii characters in a cp932_bin column: SET names utf8; DROP TABLE IF EXISTS t1; CREATE TABLE t1 (a VARCHAR (10) COLLATE cp932_bin); INSERT INTO t1 VALUES ( 'aa' ); SELECT * FROM t1 WHERE a LIKE '%a' ; and with the default collation for cp932: SET names utf8; DROP TABLE IF EXISTS t1; CREATE TABLE t1 (a VARCHAR (10) CHARACTER SET cp932); INSERT INTO t1 VALUES ( 'aa' ); SELECT * FROM t1 WHERE a LIKE '%a' ;
            bar Alexander Barkov added a comment -

            Also repeatable with latin1 character set:

            SET names utf8;
            		 
            DROP TABLE IF EXISTS t1;
            		 
            CREATE TABLE t1 (a VARCHAR(10) CHARACTER SET latin1);
            		 
            INSERT INTO t1 VALUES('aa');
            		 
            SELECT * FROM t1 WHERE a LIKE '%a';

            bar Alexander Barkov added a comment - Also repeatable with latin1 character set: SET names utf8; DROP TABLE IF EXISTS t1; CREATE TABLE t1 (a VARCHAR (10) CHARACTER SET latin1); INSERT INTO t1 VALUES ( 'aa' ); SELECT * FROM t1 WHERE a LIKE '%a' ;

            People

              bar Alexander Barkov
              elenst Elena Stepanova
              Votes:
              0 Vote for this issue
              Watchers:
              3 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.