[MDEV-10800] Assertion `outer_context || !*from_field || *from_field == not_found_field' failed (another one) Created: 2016-09-12  Updated: 2016-11-28  Resolved: 2016-11-28

Status: Closed
Project: MariaDB Server
Component/s: Optimizer
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

Sprint: 10.2.4-1

 Description    

mysqld: /data/src/10.2/sql/item.cc:4875: int Item_field::fix_outer_field(THD*, Field**, Item**): Assertion `outer_context || !*from_field || *from_field == not_found_field' failed.
 
161024 17:11:54 [ERROR] mysqld got signal 6 ;

10.2 82b974a1b60

 
#7  0x00007fa2d7e12312 in __GI___assert_fail (assertion=0x7fa2db1ffc38 "outer_context || !*from_field || *from_field == not_found_field", file=0x7fa2db1ff5e8 "/data/src/10.2/sql/item.cc", line=4875, function=0x7fa2db201e60 <Item_field::fix_outer_field(THD*, Field**, Item**)::__PRETTY_FUNCTION__> "int Item_field::fix_outer_field(THD*, Field**, Item**)") at assert.c:101
 
#8  0x00007fa2da94a522 in Item_field::fix_outer_field (this=0x7fa2cf11b5e8, thd=0x7fa2cf016070, from_field=0x7fa2db7de360, reference=0x7fa2cf11b870) at /data/src/10.2/sql/item.cc:4874
 
#9  0x00007fa2da94b8a7 in Item_field::fix_fields (this=0x7fa2cf11b5e8, thd=0x7fa2cf016070, reference=0x7fa2cf11b870) at /data/src/10.2/sql/item.cc:5299
 
#10 0x00007fa2da99c13f in Item_func::fix_fields (this=0x7fa2cf11b7d8, thd=0x7fa2cf016070, ref=0x7fa2cf118fe0) at /data/src/10.2/sql/item_func.cc:209
 
#11 0x00007fa2da703430 in JOIN::optimize_inner (this=0x7fa2cf118be8) at /data/src/10.2/sql/sql_select.cc:1255
 
#12 0x00007fa2da702b62 in JOIN::optimize (this=0x7fa2cf118be8) at /data/src/10.2/sql/sql_select.cc:1076
 
#13 0x00007fa2da695745 in mysql_derived_optimize (thd=0x7fa2cf016070, lex=0x7fa2cf019a78, derived=0x7fa2cf066160) at /data/src/10.2/sql/sql_derived.cc:866
 
#14 0x00007fa2da694172 in mysql_handle_single_derived (lex=0x7fa2cf019a78, derived=0x7fa2cf066160, phases=4) at /data/src/10.2/sql/sql_derived.cc:197
 
#15 0x00007fa2da7036c5 in JOIN::optimize_inner (this=0x7fa2cf1185d0) at /data/src/10.2/sql/sql_select.cc:1284
 
#16 0x00007fa2da702b62 in JOIN::optimize (this=0x7fa2cf1185d0) at /data/src/10.2/sql/sql_select.cc:1076
 
#17 0x00007fa2da6b42b1 in st_select_lex::optimize_unflattened_subqueries (this=0x7fa2cf01a278, const_only=false) at /data/src/10.2/sql/sql_lex.cc:3803
 
#18 0x00007fa2da860b5e in JOIN::optimize_unflattened_subqueries (this=0x7fa2cf069830) at /data/src/10.2/sql/opt_subselect.cc:5047
 
#19 0x00007fa2da705c82 in JOIN::optimize_inner (this=0x7fa2cf069830) at /data/src/10.2/sql/sql_select.cc:1937
 
#20 0x00007fa2da702b62 in JOIN::optimize (this=0x7fa2cf069830) at /data/src/10.2/sql/sql_select.cc:1076
 
#21 0x00007fa2da70b412 in mysql_select (thd=0x7fa2cf016070, tables=0x7fa2cf066d00, wild_num=1, fields=..., conds=0x0, og_num=0, order=0x0, group=0x0, having=0x0, proc_param=0x0, select_options=2147748608, result=0x7fa2cf069810, unit=0x7fa2cf019b40, select_lex=0x7fa2cf01a278) at /data/src/10.2/sql/sql_select.cc:3555
 
#22 0x00007fa2da7005c1 in handle_select (thd=0x7fa2cf016070, lex=0x7fa2cf019a78, result=0x7fa2cf069810, setup_tables_done_option=0) at /data/src/10.2/sql/sql_select.cc:373
 
#23 0x00007fa2da6cdc56 in execute_sqlcom_select (thd=0x7fa2cf016070, all_tables=0x7fa2cf066d00) at /data/src/10.2/sql/sql_parse.cc:6353
 
#24 0x00007fa2da6c3730 in mysql_execute_command (thd=0x7fa2cf016070) at /data/src/10.2/sql/sql_parse.cc:3377
 
#25 0x00007fa2da6d1616 in mysql_parse (thd=0x7fa2cf016070, rawbuf=0x7fa2cf064088 "SELECT * FROM ( SELECT * FROM t1 WHERE EXISTS ( SELECT * FROM v2 WHERE b = a ) ) AS sq", length=86, parser_state=0x7fa2db7dfdd0, is_com_multi=false, is_next_command=false) at /data/src/10.2/sql/sql_parse.cc:7796
 
#26 0x00007fa2da6bf384 in dispatch_command (command=COM_QUERY, thd=0x7fa2cf016070, packet=0x7fa2cf058071 "SELECT * FROM ( SELECT * FROM t1 WHERE EXISTS ( SELECT * FROM v2 WHERE b = a ) ) AS sq", packet_length=86, is_com_multi=false, is_next_command=false) at /data/src/10.2/sql/sql_parse.cc:1806
 
#27 0x00007fa2da6bdd5e in do_command (thd=0x7fa2cf016070) at /data/src/10.2/sql/sql_parse.cc:1366
 
#28 0x00007fa2da804474 in do_handle_one_connection (connect=0x7fa2d746d410) at /data/src/10.2/sql/sql_connect.cc:1354
 
#29 0x00007fa2da804201 in handle_one_connection (arg=0x7fa2d746d410) at /data/src/10.2/sql/sql_connect.cc:1260
 
#30 0x00007fa2dab37d78 in pfs_spawn_thread (arg=0x7fa2d74519f0) at /data/src/10.2/storage/perfschema/pfs.cc:1862
 
#31 0x00007fa2d9d140a4 in start_thread (arg=0x7fa2db7e1300) at pthread_create.c:309
 
#32 0x00007fa2d7ecc87d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111


CREATE TABLE t1 (a INT) ENGINE=MyISAM;
 
INSERT INTO t1 VALUES (1);
 
 
 
CREATE TABLE t2 (b INT) ENGINE=MyISAM;
 
INSERT INTO t2 VALUES (3),(4);
 
CREATE OR REPLACE ALGORITHM=TEMPTABLE VIEW v2 AS SELECT * FROM t2;
 
 
 
SELECT * FROM ( SELECT * FROM t1 WHERE EXISTS ( SELECT * FROM v2 WHERE b = a ) ) AS sq;



 Comments   
Comment by Elena Stepanova [ 2016-09-21 ]

Stopped happening after this commit:

commit c22d307afa1a6accbfe9857256cad01c1eacd677
 
Author: Igor Babaev <igor@askmonty.org>
 
Date:   Wed Sep 14 01:06:45 2016 -0700
 
 
 
    Fixed bug mdev-10785.
 
    The condition pushed into WHERE/HAVING of a materialized
 
    view/derived table may differ for different executions of
 
    the same prepared statement. That's why the should be
 
    ANDed with the existing WHERE/HAVING conditions only after all
 
    permanent transformations of these conditions has been
 
    performed.

Comment by Elena Stepanova [ 2016-10-10 ]

Started happening again
http://buildbot.askmonty.org/buildbot/builders/win-rqg-se/builds/2763/steps/rqg_opt_comparison/logs/stdio

(but it started earlier, to be found when).

Comment by Oleksandr Byelkin [ 2016-11-06 ]

(gdb) p current_sel->master_unit()>first_select()>linkage
$12 = DERIVED_TABLE_TYPE
(gdb) p dbug_print_select(current_sel->master_unit()->first_select())
$13 = 0x55555707b080 <dbug_item_print_buf> "select t2.b AS b from test.t2 where (t2.b = a)"
(gdb)

i.e. view has 'linkage' of derived table somehow (it looks like check of linkage is bot correct test for derived table any more)

Comment by Oleksandr Byelkin [ 2016-11-06 ]

Actually, yes. View resolving should not step over view border, so question is how it happened that external field has current select of view...

Comment by Oleksandr Byelkin [ 2016-11-08 ]

TABLE_LIST::build_pushable_cond_for_table makes item with incorrect context which can't be re-prepared

Comment by Oleksandr Byelkin [ 2016-11-08 ]

It looks like bug is in Item_field::fix_outer_field, where as start point taken current select from THD, but not from the context.

Comment by Oleksandr Byelkin [ 2016-11-08 ]

revision-id: 014bc296a582a242509b8da260591fa7738d9958 (mariadb-10.2.2-68-g014bc29)
parent(s): 99d07aa9bd7474f96052dd1adb3d98498554faf1
committer: Oleksandr Byelkin
timestamp: 2016-11-08 15:02:08 +0100
message:

MDEV-10800 Assertion `outer_context || !*from_field || *from_field == not_found_field' failed (another one)

Taking of start point of SELECT_LEX chain fixed.

Added logging for important operations.

—

Comment by Igor Babaev [ 2016-11-28 ]

This bug was fixed by the patch for bug mdev-11072. (This fix later was corrected in
the patch for bug mdev-11313.)

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