[MDEV-7086] main.ctype_cp932 fails in buildbot on a valgrind build Created: 2014-11-12  Updated: 2014-11-18  Resolved: 2014-11-18

Status: Closed
Project: MariaDB Server
Component/s: Optimizer
Affects Version/s: 10.0
Fix Version/s: 10.0.15

Type: Bug Priority: Critical
Reporter: Elena Stepanova Assignee: Alexander Barkov
Resolution: Fixed Votes: 0
Labels: buildbot, tests, valgrind

Issue Links:
Blocks
blocks MDEV-7069 Fix buildbot failures in main server ... Stalled

 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



 Comments   
Comment by Sergei Petrunia [ 2014-11-12 ]

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

Comment by Sergei Petrunia [ 2014-11-12 ]

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.

Comment by Sergei Petrunia [ 2014-11-12 ]

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)

Comment by Sergei Petrunia [ 2014-11-12 ]

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

Comment by Sergei Petrunia [ 2014-11-12 ]

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.

Comment by Sergei Petrunia [ 2014-11-12 ]

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

Comment by Alexander Barkov [ 2014-11-17 ]

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';

Comment by Alexander Barkov [ 2014-11-17 ]

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';

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