[MDEV-15738] Server crashes in my_strcasecmp_utf8 on query from I_S with UNION executed as PS Created: 2018-03-29  Updated: 2018-04-05  Resolved: 2018-04-05

Status: Closed
Project: MariaDB Server
Component/s: Information Schema, Prepared Statements
Affects Version/s: 10.3
Fix Version/s: 10.3.6

Type: Bug Priority: Critical
Reporter: Elena Stepanova Assignee: Michael Widenius
Resolution: Fixed Votes: 0
Labels: 10.3-ga, regression


 Description   

If it doesn't crash, run with ASAN.

PREPARE stmt FROM "SELECT * FROM INFORMATION_SCHEMA.GLOBAL_STATUS UNION SELECT * FROM INFORMATION_SCHEMA.GLOBAL_STATUS";
EXECUTE stmt;

#3  <signal handler called>
#4  0x0000560d599a56f7 in my_strcasecmp_utf8 (cs=0x560d5a602200 <my_charset_utf8_general_ci>, s=0x560d59a3efb1 "VARIABLE_NAME", t=0x0) at /data/src/10.3/strings/ctype-utf8.c:5302
#5  0x0000560d58f7797a in mark_all_fields_used_in_query (thd=0x7f4be0000b00, schema_fields=0x560d5a41c900 <variables_fields_info>, bitmap=0x7f4bf23f76a0, all_items=0x7f4be0128768) at /data/src/10.3/sql/sql_show.cc:8107
#6  0x0000560d58f77bcb in create_schema_table (thd=0x7f4be0000b00, table_list=0x7f4be01268f8) at /data/src/10.3/sql/sql_show.cc:8167
#7  0x0000560d58f7955e in mysql_schema_table (thd=0x7f4be0000b00, lex=0x7f4be0124ec0, table_list=0x7f4be01268f8) at /data/src/10.3/sql/sql_show.cc:8529
#8  0x0000560d58e3e10c in open_and_process_table (thd=0x7f4be0000b00, lex=0x7f4be0124ec0, tables=0x7f4be01268f8, counter=0x7f4bf23f79d4, flags=0, prelocking_strategy=0x7f4bf23f7a50, has_prelocking_list=false, ot_ctx=0x7f4bf23f7940) at /data/src/10.3/sql/sql_base.cc:3392
#9  0x0000560d58e3f7d1 in open_tables (thd=0x7f4be0000b00, options=..., start=0x7f4bf23f79b8, counter=0x7f4bf23f79d4, flags=0, prelocking_strategy=0x7f4bf23f7a50) at /data/src/10.3/sql/sql_base.cc:4032
#10 0x0000560d58e41528 in open_and_lock_tables (thd=0x7f4be0000b00, options=..., tables=0x7f4be01268f8, derived=true, flags=0, prelocking_strategy=0x7f4bf23f7a50) at /data/src/10.3/sql/sql_base.cc:4907
#11 0x0000560d58e026db in open_and_lock_tables (thd=0x7f4be0000b00, tables=0x7f4be01268f8, derived=true, flags=0) at /data/src/10.3/sql/sql_base.h:489
#12 0x0000560d58ed1286 in execute_sqlcom_select (thd=0x7f4be0000b00, all_tables=0x7f4be01268f8) at /data/src/10.3/sql/sql_parse.cc:6477
#13 0x0000560d58ec7dc2 in mysql_execute_command (thd=0x7f4be0000b00) at /data/src/10.3/sql/sql_parse.cc:3770
#14 0x0000560d58ef2cf8 in Prepared_statement::execute (this=0x7f4be0006a60, expanded_query=0x7f4bf23f93f0, open_cursor=false) at /data/src/10.3/sql/sql_prepare.cc:4740
#15 0x0000560d58ef110d in Prepared_statement::execute_loop (this=0x7f4be0006a60, expanded_query=0x7f4bf23f93f0, open_cursor=false, packet=0x0, packet_end=0x0) at /data/src/10.3/sql/sql_prepare.cc:4170
#16 0x0000560d58eeed2b in mysql_sql_stmt_execute (thd=0x7f4be0000b00) at /data/src/10.3/sql/sql_prepare.cc:3278
#17 0x0000560d58ec7e07 in mysql_execute_command (thd=0x7f4be0000b00) at /data/src/10.3/sql/sql_parse.cc:3786
#18 0x0000560d58ed5150 in mysql_parse (thd=0x7f4be0000b00, rawbuf=0x7f4be0014d48 "EXECUTE stmt", length=12, parser_state=0x7f4bf23fa5d0, is_com_multi=false, is_next_command=false) at /data/src/10.3/sql/sql_parse.cc:8013
#19 0x0000560d58ec2803 in dispatch_command (command=COM_QUERY, thd=0x7f4be0000b00, packet=0x7f4be008fed1 "EXECUTE stmt", packet_length=12, is_com_multi=false, is_next_command=false) at /data/src/10.3/sql/sql_parse.cc:1842
#20 0x0000560d58ec1242 in do_command (thd=0x7f4be0000b00) at /data/src/10.3/sql/sql_parse.cc:1387
#21 0x0000560d59025af5 in do_handle_one_connection (connect=0x560d5ca48dd0) at /data/src/10.3/sql/sql_connect.cc:1402
#22 0x0000560d59025882 in handle_one_connection (arg=0x560d5ca48dd0) at /data/src/10.3/sql/sql_connect.cc:1308
#23 0x0000560d594ac861 in pfs_spawn_thread (arg=0x560d5ca5c670) at /data/src/10.3/storage/perfschema/pfs.cc:1862
#24 0x00007f4bf9f2a494 in start_thread (arg=0x7f4bf23fb700) at pthread_create.c:333
#25 0x00007f4bf831093f in clone () from /lib/x86_64-linux-gnu/libc.so.6

The problem was introduced by this commit:

commit e2664ee8362a94335df06edfc86936ff263d6dc0
Author: Monty <monty@mariadb.org>
Date:   Mon Mar 26 17:22:41 2018 +0300
 
    MDEV-14275 Improving memory utilization for information schema



 Comments   
Comment by Michael Widenius [ 2018-04-05 ]

Problem was the Item_field::Item_field(THD*, Field*) had old code
that put a null pointer in orig_field_names. Now, when we have
proper re-prepare if table definition changes, this is not needed
anymore.

Generated at Thu Feb 08 08:23:38 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.