[MDEV-11072] Server crashes in find_field_in_tables Created: 2016-10-17  Updated: 2016-11-18  Resolved: 2016-11-17

Status: Closed
Project: MariaDB Server
Component/s: Optimizer, Views
Affects Version/s: 10.2
Fix Version/s: 10.2.3

Type: Bug Priority: Critical
Reporter: Elena Stepanova Assignee: Igor Babaev
Resolution: Fixed Votes: 0
Labels: regression-10.2

Issue Links:
Relates
relates to MDEV-11313 Server crashes in find_field_in_table... Closed
Sprint: 10.2.4-2

 Description    

CREATE TABLE t1 (a INT);
 
CREATE OR REPLACE VIEW v1 AS SELECT * FROM t1;
 
 
 
CREATE TABLE t2 (b INT);
 
CREATE OR REPLACE VIEW v2 AS SELECT * FROM t2;
 
 
 
CREATE TABLE t3 (c INT);
 
CREATE OR REPLACE ALGORITHM=TEMPTABLE VIEW v3 AS SELECT * FROM t3;
 
 
 
SELECT * FROM t1 WHERE a IN ( 
  SELECT b FROM v2 WHERE b < a OR b IN ( 
    SELECT c FROM v3 WHERE c = a 
  ) 
);

10.2 057c560ee4

 
#3  <signal handler called>
 
#4  0x00007feb32856710 in find_field_in_tables (thd=0x7feb27016070, item=0x7feb27120dc8, first_table=0x7feb27066d58, last_table=0x0, ref=0x7feb27122c30, report_error=IGNORE_EXCEPT_NON_UNIQUE, check_privileges=true, register_tree_change=true) at /data/src/10.2/sql/sql_base.cc:5731
 
#5  0x00007feb32b44b9f in Item_field::fix_fields (this=0x7feb27120dc8, thd=0x7feb27016070, reference=0x7feb27122c30) at /data/src/10.2/sql/item.cc:5204
 
#6  0x00007feb32b93be7 in Item_func::fix_fields (this=0x7feb27122b98, thd=0x7feb27016070, ref=0x7feb2711dab8) at /data/src/10.2/sql/item_func.cc:209
 
#7  0x00007feb328fd382 in JOIN::optimize_inner (this=0x7feb2711d6c0) at /data/src/10.2/sql/sql_select.cc:1255
 
#8  0x00007feb328fcab4 in JOIN::optimize (this=0x7feb2711d6c0) at /data/src/10.2/sql/sql_select.cc:1076
 
#9  0x00007feb3288f739 in mysql_derived_optimize (thd=0x7feb27016070, lex=0x7feb27019a78, derived=0x7feb27066d58) at /data/src/10.2/sql/sql_derived.cc:866
 
#10 0x00007feb3288e166 in mysql_handle_single_derived (lex=0x7feb27019a78, derived=0x7feb27066d58, phases=4) at /data/src/10.2/sql/sql_derived.cc:197
 
#11 0x00007feb328fd617 in JOIN::optimize_inner (this=0x7feb2711d0a8) at /data/src/10.2/sql/sql_select.cc:1284
 
#12 0x00007feb328fcab4 in JOIN::optimize (this=0x7feb2711d0a8) at /data/src/10.2/sql/sql_select.cc:1076
 
#13 0x00007feb328ae2a5 in st_select_lex::optimize_unflattened_subqueries (this=0x7feb2701a278, const_only=false) at /data/src/10.2/sql/sql_lex.cc:3803
 
#14 0x00007feb32a5a474 in JOIN::optimize_unflattened_subqueries (this=0x7feb2711a6b0) at /data/src/10.2/sql/opt_subselect.cc:5047
 
#15 0x00007feb32900345 in JOIN::optimize_inner (this=0x7feb2711a6b0) at /data/src/10.2/sql/sql_select.cc:2121
 
#16 0x00007feb328fcab4 in JOIN::optimize (this=0x7feb2711a6b0) at /data/src/10.2/sql/sql_select.cc:1076
 
#17 0x00007feb32905364 in mysql_select (thd=0x7feb27016070, tables=0x7feb27064310, wild_num=1, fields=..., conds=0x7feb27067a28, og_num=0, order=0x0, group=0x0, having=0x0, proc_param=0x0, select_options=2147748608, result=0x7feb27069f68, unit=0x7feb27019b40, select_lex=0x7feb2701a278) at /data/src/10.2/sql/sql_select.cc:3555
 
#18 0x00007feb328fa513 in handle_select (thd=0x7feb27016070, lex=0x7feb27019a78, result=0x7feb27069f68, setup_tables_done_option=0) at /data/src/10.2/sql/sql_select.cc:373
 
#19 0x00007feb328c7c2e in execute_sqlcom_select (thd=0x7feb27016070, all_tables=0x7feb27064310) at /data/src/10.2/sql/sql_parse.cc:6353
 
#20 0x00007feb328bd708 in mysql_execute_command (thd=0x7feb27016070) at /data/src/10.2/sql/sql_parse.cc:3377
 
#21 0x00007feb328cb5ee in mysql_parse (thd=0x7feb27016070, rawbuf=0x7feb27064088 "SELECT * FROM t1 WHERE a IN ( \nSELECT b FROM v2 WHERE b < a OR b IN ( \nSELECT c FROM v3 WHERE c = a \n) \n)", length=105, parser_state=0x7feb339cbdd0, is_com_multi=false, is_next_command=false) at /data/src/10.2/sql/sql_parse.cc:7796
 
#22 0x00007feb328b935c in dispatch_command (command=COM_QUERY, thd=0x7feb27016070, packet=0x7feb27058071 "SELECT * FROM t1 WHERE a IN ( \nSELECT b FROM v2 WHERE b < a OR b IN ( \nSELECT c FROM v3 WHERE c = a \n) \n)", packet_length=105, is_com_multi=false, is_next_command=false) at /data/src/10.2/sql/sql_parse.cc:1806
 
#23 0x00007feb328b7d36 in do_command (thd=0x7feb27016070) at /data/src/10.2/sql/sql_parse.cc:1366
 
#24 0x00007feb329fde14 in do_handle_one_connection (connect=0x7feb2f46d410) at /data/src/10.2/sql/sql_connect.cc:1354
 
#25 0x00007feb329fdba1 in handle_one_connection (arg=0x7feb2f46d410) at /data/src/10.2/sql/sql_connect.cc:1260
 
#26 0x00007feb32d2a32c in pfs_spawn_thread (arg=0x7feb2f4519f0) at /data/src/10.2/storage/perfschema/pfs.cc:1862
 
#27 0x00007feb31f260a4 in start_thread (arg=0x7feb339cd300) at pthread_create.c:309
 
#28 0x00007feb300de87d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111



 Comments   
Comment by Oleksandr Byelkin [ 2016-11-09 ]

(gdb) p dbug_print_select(select_lex)
$4 = 0x55555707b160 <dbug_item_print_buf> "select t3.c AS c from test.t3 where (t3.c = a)"

so it is subquery but has no Item (Why???)

Comment by Oleksandr Byelkin [ 2016-11-10 ]

OK, the select despite the WHERE condition is actually VIEW (checked).
and the Item which can't be re-prepared was created in TABLE_LIST::build_pushable_cond_for_table() (also checked).

Now we have Item pushed in the view which trying to trace back its outer depending starting from view (naturally it fail).
IMHO tracing from such items should start from the SELECT where they were taken.

Comment by Igor Babaev [ 2016-11-15 ]

A fix for the bug has been sent for review.

Comment by Oleksandr Byelkin [ 2016-11-15 ]


Thank you a lot, OK to push!

Comment by Igor Babaev [ 2016-11-17 ]

The fix for this bug was pushed into the 10.2 tree.

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