[MDEV-20643] Server crashes in find_table_in_list upon INSERT .. SELECT after dropping a database Created: 2019-09-21  Updated: 2021-01-19  Resolved: 2021-01-19

Status: Closed
Project: MariaDB Server
Component/s: Server
Affects Version/s: 10.2
Fix Version/s: 10.2.37

Type: Bug Priority: Major
Reporter: Elena Stepanova Assignee: Rucha Deodhar
Resolution: Fixed Votes: 0
Labels: None


 Description   

Note: The test case is non-deterministic, run with --repeat=N. Also, --mem seems to be important, probably due to a different dynamics on disk. With --mem it usually fails for me within 1-2 first attempts, but it can vary on different machines and builds.

--source include/have_innodb.inc
 
CREATE TABLE t1 (a INT) ENGINE=MEMORY;
CREATE SCHEMA db;
CREATE PROCEDURE db.pr() SELECT * FROM test.t1; 
 
--connect (con1,localhost,root,,test)
--let $con1_id= `SELECT CONNECTION_ID()`
--send
  DROP DATABASE db;
 
--connection default
SELECT * FROM t1;
--eval KILL $con1_id
 
--error 0,ER_BAD_DB_ERROR,ER_SP_DOES_NOT_EXIST
CALL db.pr;
CREATE TABLE test.t2 LIKE test.t1  ;
INSERT test.t2 WITH cte AS ( SELECT * FROM test.t1 ) SELECT * FROM cte;
 
# Partial cleanup
# (full cleanup is not always possible due to MDEV-20642)
--connection con1
--error 0,2013
--reap
--connection default
DROP DATABASE IF EXISTS db;
DROP TABLE IF EXISTS test.t1, test.t2;

10.2 1ad79c81

#3  <signal handler called>
#4  __strcmp_sse2_unaligned () at ../sysdeps/x86_64/multiarch/strcmp-sse2-unaligned.S:31
#5  0x000055c194dfd52d in find_table_in_list (table=0x7f9a28014128, link=&TABLE_LIST::next_global, db_name=0x7f9a28012568 "test", table_name=0x7f9a28012570 "t2") at /data/src/10.2/sql/sql_base.cc:942
#6  0x000055c194e12635 in find_table_in_global_list (table=0x7f9a280138d0, db_name=0x7f9a28012568 "test", table_name=0x7f9a28012570 "t2") at /data/src/10.2/sql/sql_base.h:360
#7  0x000055c194dfd74e in find_dup_table (thd=0x7f9a28000b00, table=0x7f9a280125b0, table_list=0x7f9a280138d0, check_flag=0) at /data/src/10.2/sql/sql_base.cc:1036
#8  0x000055c194dfda7d in unique_table (thd=0x7f9a28000b00, table=0x7f9a280125b0, table_list=0x7f9a280138d0, check_flag=0) at /data/src/10.2/sql/sql_base.cc:1139
#9  0x000055c194e53490 in select_insert::prepare (this=0x7f9a28015058, values=..., u=0x7f9a28004700) at /data/src/10.2/sql/sql_insert.cc:3638
#10 0x000055c194eb22b9 in JOIN::prepare (this=0x7f9a28015100, tables_init=0x7f9a28014128, wild_num=1, conds_init=0x0, og_num=0, order_init=0x0, skip_order_by=false, group_init=0x0, having_init=0x0, proc_param_init=0x0, select_lex_arg=0x7f9a28004e40, unit_arg=0x7f9a28004700) at /data/src/10.2/sql/sql_select.cc:1049
#11 0x000055c194ebb9ca in mysql_select (thd=0x7f9a28000b00, tables=0x7f9a28014128, wild_num=1, fields=..., conds=0x0, og_num=0, order=0x0, group=0x0, having=0x0, proc_param=0x0, select_options=3489925888, result=0x7f9a28015058, unit=0x7f9a28004700, select_lex=0x7f9a28004e40) at /data/src/10.2/sql/sql_select.cc:3796
#12 0x000055c194eafce8 in handle_select (thd=0x7f9a28000b00, lex=0x7f9a28004638, result=0x7f9a28015058, setup_tables_done_option=1073741824) at /data/src/10.2/sql/sql_select.cc:361
#13 0x000055c194e73c79 in mysql_execute_command (thd=0x7f9a28000b00) at /data/src/10.2/sql/sql_parse.cc:4283
#14 0x000055c194e7ed64 in mysql_parse (thd=0x7f9a28000b00, rawbuf=0x7f9a28012468 "INSERT test.t2 WITH cte AS ( SELECT * FROM test.t1 ) SELECT * FROM cte", length=70, parser_state=0x7f9a7aa04200, is_com_multi=false, is_next_command=false) at /data/src/10.2/sql/sql_parse.cc:7759
#15 0x000055c194e6d06d in dispatch_command (command=COM_QUERY, thd=0x7f9a28000b00, packet=0x7f9a28096371 "INSERT test.t2 WITH cte AS ( SELECT * FROM test.t1 ) SELECT * FROM cte", packet_length=70, is_com_multi=false, is_next_command=false) at /data/src/10.2/sql/sql_parse.cc:1831
#16 0x000055c194e6b9c1 in do_command (thd=0x7f9a28000b00) at /data/src/10.2/sql/sql_parse.cc:1384
#17 0x000055c194fc0b83 in do_handle_one_connection (connect=0x55c1990be250) at /data/src/10.2/sql/sql_connect.cc:1336
#18 0x000055c194fc08ee in handle_one_connection (arg=0x55c1990be250) at /data/src/10.2/sql/sql_connect.cc:1241
#19 0x000055c1957f19fa in pfs_spawn_thread (arg=0x55c1990e1500) at /data/src/10.2/storage/perfschema/pfs.cc:1862
#20 0x00007f9a81f2c4a4 in start_thread (arg=0x7f9a7aa05700) at pthread_create.c:456
#21 0x00007f9a80474d0f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:97

All of 10.2 debug, ASAN and non-debug fail with the same SEGV.
Couldn't reproduce on 10.3+.
The test case is not applicable to 10.1.



 Comments   
Comment by Rucha Deodhar [ 2020-06-24 ]

Reason: Crash happens because in find_table_in_list() function, table->db is NULL which is passed to strcmp().
possible fix: Use a safe string as argument (safe_str() function) which returns empty string when (char *) is NULL otherwise returns the same string if (char *) is not NULL.

Comment by Rucha Deodhar [ 2020-06-24 ]

Patch: https://github.com/MariaDB/server/commit/4c2cde1bef1533dd989cb6a37c482c3437d66403

Comment by Oleksandr Byelkin [ 2020-10-14 ]

IMHO it is incorrect that names are NULL as I remember it shoud be empty string, please check where it is assigned as NULL.

Generated at Thu Feb 08 09:01:04 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.