[MDEV-12633] Conditional jump or move depends on uninitialised value in my_scan_weight_utf8_general_ci, main.mysql_client_test fails in biuldbot with valgrind Created: 2017-04-29  Updated: 2017-11-02  Resolved: 2017-11-02

Status: Closed
Project: MariaDB Server
Component/s: Plugins, Server, Tests
Affects Version/s: 10.1, 10.2
Fix Version/s: 10.1.29, 10.2.11

Type: Bug Priority: Major
Reporter: Elena Stepanova Assignee: Michael Widenius
Resolution: Fixed Votes: 0
Labels: None


 Description   

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

main.mysql_client_test                   w3 [ fail ]  Found warnings/errors in server log file!
 
        Test ended at 2017-04-27 08:29:11
 
line
 
==7510== Thread 7:
 
==7510== Conditional jump or move depends on uninitialised value(s)
 
==7510==    at 0xF65694: my_scan_weight_utf8_general_ci (strcoll.ic:89)
 
==7510==    by 0xF6584D: my_strnncoll_utf8_general_ci (strcoll.ic:175)
 
==7510==    by 0xEEFA4D: hashcmp (hash.c:370)
 
==7510==    by 0xEEF821: my_hash_first_from_hash_value (hash.c:285)
 
==7510==    by 0xEEF76C: my_hash_first (hash.c:257)
 
==7510==    by 0xEEF6C3: my_hash_search (hash.c:231)
 
==7510==    by 0x6331F9: plugin_find_internal(st_mysql_lex_string const*, int) (sql_plugin.cc:900)
 
==7510==    by 0x633627: plugin_lock_by_name(THD*, st_mysql_lex_string const*, int) (sql_plugin.cc:1026)
 
==7510==    by 0x874809: ha_table_exists(THD*, char const*, char const*, handlerton**) (handler.cc:5034)
 
==7510==    by 0x6D4B12: mysql_rm_table_no_locks(THD*, TABLE_LIST*, bool, bool, bool, bool, bool) (sql_table.cc:2399)
 
==7510==    by 0x6D4087: mysql_rm_table(THD*, TABLE_LIST*, char, char) (sql_table.cc:2084)
 
==7510==    by 0x621276: mysql_execute_command(THD*) (sql_parse.cc:4243)
 
==7510== Use of uninitialised value of size 8
 
==7510==    at 0xF65549: my_weight_mb1_utf8_general_ci (ctype-utf8.c:5362)
 
==7510==    by 0xF656A6: my_scan_weight_utf8_general_ci (strcoll.ic:91)
 
==7510==    by 0xF6584D: my_strnncoll_utf8_general_ci (strcoll.ic:175)
 
==7510==    by 0xEEFA4D: hashcmp (hash.c:370)
 
==7510==    by 0xEEF821: my_hash_first_from_hash_value (hash.c:285)
 
==7510==    by 0xEEF76C: my_hash_first (hash.c:257)
 
==7510==    by 0xEEF6C3: my_hash_search (hash.c:231)
 
==7510==    by 0x6331F9: plugin_find_internal(st_mysql_lex_string const*, int) (sql_plugin.cc:900)
 
==7510==    by 0x633627: plugin_lock_by_name(THD*, st_mysql_lex_string const*, int) (sql_plugin.cc:1026)
 
==7510==    by 0x874809: ha_table_exists(THD*, char const*, char const*, handlerton**) (handler.cc:5034)
 
==7510==    by 0x6D4B12: mysql_rm_table_no_locks(THD*, TABLE_LIST*, bool, bool, bool, bool, bool) (sql_table.cc:2399)
 
==7510==    by 0x6D4087: mysql_rm_table(THD*, TABLE_LIST*, char, char) (sql_table.cc:2084)

Also reproducible locally.

 Comments   
Comment by Elena Stepanova [ 2017-04-29 ]

main.mysql_client_test_nonblock, main.show_check, main.mysqlcheck, main.mysql_client_test_comp, main.drop-no_root are also affected.

Comment by Alexander Barkov [ 2017-11-02 ]

The failure is repeatable with this simplified test file:

# Create a junk frm file on disk
 
let $MYSQLD_DATADIR= `select @@datadir`;
 
system echo "this is a junk file for test" >> $MYSQLD_DATADIR/test/t1.frm ;
 
--replace_column 6 # 7 # 8 # 9 # 12 #
 
SHOW TABLE STATUS like 't1';
 
--error ER_NOT_FORM_FILE
 
show create table t1;
 
--disable_warnings
 
drop table if exists t1;
 
--enable_warnings
 
--error 1,0
 
--remove_file $MYSQLD_DATADIR/test/t1.frm

The failure happens because dd_frm_type() leaves the engine_name argument uninitialized when it could not read the engine name from a junk FRM file, while it still returns FRMTYPE_TABLE. So the caller does not know that engine_name is not properly set and continues with searching a handler by name.

Perhaps dd_frm_type() should be fixed to return FRMTYPE_ERROR in such cases.

Comment by Michael Widenius [ 2017-11-02 ]

We can't return FRMTYPE_ERROR from dd_frm_type if the .frm file exists, as otherwise we would not be able to drop a bad .frm file with 'drop table'

Simple fix is to just ensure that engine_name is an empty string, if something goes wrong.

Comment by Michael Widenius [ 2017-11-02 ]

Fix pushed

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