[MDEV-7086] main.ctype_cp932 fails in buildbot on a valgrind build - Jira

Details

Type: Bug
Status: Closed (View Workflow)
Priority: Critical
Resolution: Fixed
Affects Version/s: 10.0(EOL)
Fix Version/s: 10.0.15
Component/s: Optimizer
Labels:
- buildbot
- tests
- valgrind

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

MDEV-7069 Fix buildbot failures in main server trees

Stalled

Activity

Ascending order - Click to sort in descending order

Elena Stepanova created issue - 2014-11-12 03:15

Elena Stepanova made changes - 2014-11-12 03:15

Field	Original Value	New Value
Link		This issue blocks MDEV-7069 [ MDEV-7069 ]

Elena Stepanova made changes - 2014-11-12 03:18

Labels

buildbot tests

buildbot tests valgrind

Sergei Petrunia added a comment - 2014-11-12 16:03

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

Sergei Petrunia added a comment - 2014-11-12 16:03 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

Sergei Petrunia added a comment - 2014-11-12 16:11

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.

Sergei Petrunia added a comment - 2014-11-12 16:11 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.

Sergei Petrunia added a comment - 2014-11-12 17:10

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)

Sergei Petrunia added a comment - 2014-11-12 17:10 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)

Sergei Petrunia added a comment - 2014-11-12 19:43

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

Sergei Petrunia added a comment - 2014-11-12 19:43 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

Sergei Petrunia added a comment - 2014-11-12 22:53

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.

Sergei Petrunia added a comment - 2014-11-12 22:53 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.

Sergei Petrunia made changes - 2014-11-12 22:53

Assignee

Sergei Petrunia [ psergey ]

Alexander Barkov [ bar ]

Sergei Petrunia added a comment - 2014-11-12 22:53

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

Sergei Petrunia added a comment - 2014-11-12 22:53 bar , this is a charset issue. Could you take over please?

Alexander Barkov added a comment - 2014-11-17 20:51

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

Alexander Barkov added a comment - 2014-11-17 20:51 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' ;

Alexander Barkov added a comment - 2014-11-17 21:53

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

Alexander Barkov added a comment - 2014-11-17 21:53 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' ;

Alexander Barkov made changes - 2014-11-18 11:10

Resolution		Fixed [ 1 ]
Status	Open [ 1 ]	Closed [ 6 ]

Rasmus Johansson (Inactive) made changes - 2015-05-18 17:51

Workflow

MariaDB v2 [ 58427 ]

MariaDB v3 [ 65161 ]

Sergei Golubchik made changes - 2021-12-06 21:40

Workflow

MariaDB v3 [ 65161 ]

MariaDB v4 [ 148456 ]

People

Assignee:: Alexander Barkov

Reporter:: Elena Stepanova

Votes:: 0 Vote for this issue

Watchers:: 3 Start watching this issue

Dates

Created:: 2014-11-12 03:15

Updated:: 2014-11-18 11:10

Resolved:: 2014-11-18 11:10

Git Integration

Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.

MariaDB Server