[MDEV-7691] Assertion `outer_context || !*from_field || *from_field == not_found_field' failed on 2nd execution of PS with nested subqueries Created: 2015-03-10  Updated: 2017-04-04  Resolved: 2016-12-19

Status: Closed
Project: MariaDB Server
Component/s: Optimizer
Affects Version/s: 5.3.13, 5.5, 10.0, 10.1
Fix Version/s: 5.5.54

Type: Bug Priority: Critical
Reporter: Elena Stepanova Assignee: Sergei Petrunia
Resolution: Fixed Votes: 1
Labels: verified

Issue Links:
Blocks
Duplicate
duplicates MDEV-10148 Database crashes in the query to the ... Closed
duplicates MDEV-10979 mariadb 5.5.47 and 5.5.44 Crash syste... Closed
Problem/Incident
causes CONJ-348 Could not read resultset: unexpected ... Closed
Relates
relates to MDEV-11293 Hit signal 11 when excuting a procedu... Closed
relates to MDEV-8833 Crash of server on prepared statement... Closed
Sprint: 10.0.24, 5.5.50, 10.2.2-2, 10.2.2-3, 10.2.2-4, 5.5.54

 Description   

See also MDEV-7688, MDEV-7689, MDEV-7690, MDEV-7696, MDEV-7751 - they all are somewhat similar, probably there are duplicates among them; but effects are different everywhere.

Stack trace from 5.5 commit 34f37aa0c0aa87cfb6908500e937516ff37ea6f0

5.5/sql/item.cc:4806: int Item_field::fix_outer_field(THD*, Field**, Item**): Assertion `outer_context || !*from_field || *from_field == not_found_field' failed.
150310 17:48:11 [ERROR] mysqld got signal 6 ;
 
#6  0x00007fdca20ce311 in *__GI___assert_fail (assertion=0xe05880 "outer_context || !*from_field || *from_field == not_found_field", file=<optimized out>, line=4806, function=0xe07dc0 "int Item_field::fix_outer_field(THD*, Field**, Item**)") at assert.c:81#7  0x00000000007fd8f6 in Item_field::fix_outer_field (this=0x7fdc9cca88a8, thd=0x7fdca0b49060, from_field=0x7fdc9d7b39f8, reference=0x7fdc9cca3608) at sql/item.cc:4805
#8  0x00000000007feac4 in Item_field::fix_fields (this=0x7fdc9cca88a8, thd=0x7fdca0b49060, reference=0x7fdc9cca3608) at sql/item.cc:5191
#9  0x00000000005de894 in setup_fields (thd=0x7fdca0b49060, ref_pointer_array=0x7fdc9cca89c0, fields=..., mark_used_columns=MARK_COLUMNS_READ, sum_func_list=0x7fdc9cc45748, allow_sum_func=true) at sql/sql_base.cc:8169
#10 0x00000000006602ac in JOIN::prepare (this=0x7fdc9cc45418, rref_pointer_array=0x7fdc9cca2a80, tables_init=0x7fdc9cca3648, wild_num=0, conds_init=0x0, og_num=0, order_init=0x0, skip_order_by=false, group_init=0x0, having_init=0x7fdc9cca8dc0, proc_param_init=0x0, select_lex_arg=0x7fdc9cca2810, unit_arg=0x7fdc9cca2130) at sql/sql_select.cc:723
#11 0x00000000006689fb in mysql_select (thd=0x7fdca0b49060, rref_pointer_array=0x7fdc9cca2a80, tables=0x7fdc9cca3648, wild_num=0, fields=..., conds=0x0, og_num=0, order=0x0, group=0x0, having=0x7fdc9cca8dc0, proc_param=0x0, select_options=2416184064, result=0x7fdc9cca8888, unit=0x7fdc9cca2130, select_lex=0x7fdc9cca2810) at sql/sql_select.cc:3074
#12 0x000000000065f57d in handle_select (thd=0x7fdca0b49060, lex=0x7fdc9cca2080, result=0x7fdc9cca8888, setup_tables_done_option=0) at sql/sql_select.cc:319
#13 0x0000000000638728 in execute_sqlcom_select (thd=0x7fdca0b49060, all_tables=0x7fdc9cca3648) at sql/sql_parse.cc:4689
#14 0x000000000063190a in mysql_execute_command (thd=0x7fdca0b49060) at sql/sql_parse.cc:2234
#15 0x0000000000652b81 in Prepared_statement::execute (this=0x7fdc9cc92460, expanded_query=0x7fdc9d7b4c90, open_cursor=false) at sql/sql_prepare.cc:3928
#16 0x0000000000651c98 in Prepared_statement::execute_loop (this=0x7fdc9cc92460, expanded_query=0x7fdc9d7b4c90, open_cursor=false, packet=0x0, packet_end=0x0) at sql/sql_prepare.cc:3587
#17 0x000000000064fdbc in mysql_sql_stmt_execute (thd=0x7fdca0b49060) at sql/sql_prepare.cc:2737
#18 0x0000000000631938 in mysql_execute_command (thd=0x7fdca0b49060) at sql/sql_parse.cc:2244
#19 0x000000000063b20e in mysql_parse (thd=0x7fdca0b49060, rawbuf=0x7fdc9cc45078 "EXECUTE stmt", length=12, parser_state=0x7fdc9d7b5620) at sql/sql_parse.cc:5909
#20 0x000000000062ee51 in dispatch_command (command=COM_QUERY, thd=0x7fdca0b49060, packet=0x7fdc9dde8061 "EXECUTE stmt", packet_length=12) at sql/sql_parse.cc:1079
#21 0x000000000062dfdd in do_command (thd=0x7fdca0b49060) at sql/sql_parse.cc:793
#22 0x0000000000730712 in do_handle_one_connection (thd_arg=0x7fdca0b49060) at sql/sql_connect.cc:1266
#23 0x00000000007301d1 in handle_one_connection (arg=0x7fdca0b49060) at sql/sql_connect.cc:1181
#24 0x0000000000b66bad in pfs_spawn_thread (arg=0x7fdc9dd50ee0) at storage/perfschema/pfs.cc:1015
#25 0x00007fdca3871b50 in start_thread (arg=<optimized out>) at pthread_create.c:304
#26 0x00007fdca217f70d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112

Test case

CREATE TABLE t1 (a INT) ENGINE=MyISAM;
INSERT INTO t1 VALUES (4),(6);
 
CREATE TABLE t2 (b INT) ENGINE=MyISAM;
INSERT INTO t2 VALUES (1),(8);
 
PREPARE stmt FROM "
SELECT * FROM t2
HAVING 0 IN ( 
  SELECT a FROM t1 
  WHERE a IN ( 
    SELECT a FROM t1
    WHERE b = a
  )
)
"; 
 
EXECUTE stmt;
EXECUTE stmt;

Alternative test case, without HAVING

CREATE TABLE t (i INT) ENGINE=MyISAM;
INSERT INTO t VALUES (4),(6);
 
PREPARE stmt FROM "
SELECT * FROM t AS t1
WHERE EXISTS ( 
  SELECT * FROM t AS t2 WHERE t1.i IN ( 
    SELECT i FROM t 
  ) 
)";
 
EXECUTE stmt;
EXECUTE stmt;



 Comments   
Comment by Elena Stepanova [ 2015-03-11 ]

On 5.3 the same test case causes a different assertion failure:

mysqld: sql_lex.cc:1911: bool st_select_lex::mark_as_dependent(THD*, st_select_lex*, Item*): Assertion `this != last' failed.
150311 12:03:29 [ERROR] mysqld got signal 6 ;
 
#6  0x00007f158a0cd311 in *__GI___assert_fail (assertion=0xc7df22 "this != last", file=<optimized out>, line=1911, function=0xc7f080 "bool st_select_lex::mark_as_dependent(THD*, st_select_lex*, Item*)") at assert.c:81
#7  0x00000000005871e0 in st_select_lex::mark_as_dependent (this=0x26352a8, thd=0x25b4fb0, last=0x26352a8, dependency=0x26392f8) at sql_lex.cc:1911
#8  0x00000000005aa9b9 in mark_as_dependent (thd=0x25b4fb0, last=0x26352a8, current=0x26352a8, resolved_item=0x26392f8, mark_item=0x26392f8) at item.cc:4026
#9  0x00000000005abfb5 in Item_field::fix_outer_field (this=0x26392f8, thd=0x25b4fb0, from_field=0x7f15815e8828, reference=0x2602698) at item.cc:4625
#10 0x00000000005ac64e in Item_field::fix_fields (this=0x26392f8, thd=0x25b4fb0, reference=0x2602698) at item.cc:4794
#11 0x00000000007141dd in setup_fields (thd=0x25b4fb0, ref_pointer_array=0x26394a8, fields=..., mark_used_columns=MARK_COLUMNS_READ, sum_func_list=0x2639040, allow_sum_func=true) at sql_base.cc:7868
#12 0x000000000072c7d6 in JOIN::prepare (this=0x2638d08, rref_pointer_array=0x26348f8, tables_init=0x264a7e8, wild_num=0, conds_init=0x0, og_num=0, order_init=0x0, skip_order_by=false, group_init=0x0, having_init=0x263a838, proc_param_init=0x0, select_lex_arg=0x2634640, unit_arg=0x2634118) at sql_select.cc:666
#13 0x00000000007351fb in mysql_select (thd=0x25b4fb0, rref_pointer_array=0x26348f8, tables=0x264a7e8, wild_num=0, fields=..., conds=0x0, og_num=0, order=0x0, group=0x0, having=0x263a838, proc_param=0x0, select_options=2416200192, result=0x26376d8, unit=0x2634118, select_lex=0x2634640) at sql_select.cc:2987
#14 0x000000000072bc1b in handle_select (thd=0x25b4fb0, lex=0x2634078, result=0x26376d8, setup_tables_done_option=0) at sql_select.cc:288
#15 0x00000000006b9973 in execute_sqlcom_select (thd=0x25b4fb0, all_tables=0x264a7e8) at sql_parse.cc:5174
#16 0x00000000006b0b06 in mysql_execute_command (thd=0x25b4fb0) at sql_parse.cc:2307
#17 0x000000000078dcb8 in Prepared_statement::execute (this=0x2625e30, expanded_query=0x7f15815e9c70, open_cursor=false) at sql_prepare.cc:3764
#18 0x000000000078cf05 in Prepared_statement::execute_loop (this=0x2625e30, expanded_query=0x7f15815e9c70, open_cursor=false, packet=0x0, packet_end=0x0) at sql_prepare.cc:3445
#19 0x000000000078b35c in mysql_sql_stmt_execute (thd=0x25b4fb0) at sql_prepare.cc:2670
#20 0x00000000006b0b34 in mysql_execute_command (thd=0x25b4fb0) at sql_parse.cc:2316
#21 0x00000000006bc2ca in mysql_parse (thd=0x25b4fb0, rawbuf=0x26429e8 "EXECUTE stmt", length=12, found_semicolon=0x7f15815eacc8) at sql_parse.cc:6175
#22 0x00000000006ae367 in dispatch_command (command=COM_QUERY, thd=0x25b4fb0, packet=0x25fe5a1 "EXECUTE stmt", packet_length=12) at sql_parse.cc:1245
#23 0x00000000006ad640 in do_command (thd=0x25b4fb0) at sql_parse.cc:923
#24 0x00000000006aa092 in handle_one_connection (arg=0x25b4fb0) at sql_connect.cc:1231
#25 0x00007f158addbb50 in start_thread (arg=<optimized out>) at pthread_create.c:304
#26 0x00007f158a17e70d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112

Comment by Oleksandr Byelkin [ 2015-12-02 ]

The second test suite is a duplicate of MDEV-8833

Comment by Oleksandr Byelkin [ 2015-12-02 ]

Convertion to sj trying to pulluot (calls fix_after_pullout) for field which belong to main SELECT selet-list (b, created in expanding *). probably found by reference from Item_ref because all fields are under HAVING so are references (which is naturally incorrect).

Comment by Oleksandr Byelkin [ 2015-12-03 ]

so after fixing of 8833 we have following:

#0  Item_field::fix_after_pullout (this=0x7fffe0047c58, new_parent=0x7fffe00903a8, ref=0x7fffe0044e28) at /home/sanja/maria/git/server/sql/item.cc:2770
#1  0x0000000000807952 in Item_ref::fix_after_pullout (this=0x7fffe0018ec8, new_parent=0x7fffe00903a8, refptr=0x7fffe0006f50) at /home/sanja/maria/git/server/sql/item.cc:8061
#2  0x0000000000841074 in Item_func::fix_after_pullout (this=0x7fffe0006eb8, new_parent=0x7fffe00903a8, ref=0x7fffe001af78) at /home/sanja/maria/git/server/sql/item_func.cc:281
#3  0x0000000000822f1c in Item_cond::fix_after_pullout (this=0x7fffe001ae18, new_parent=0x7fffe00903a8, ref=0x7fffe001a580) at /home/sanja/maria/git/server/sql/item_cmpfunc.cc:4468
#4  0x000000000076566e in convert_subq_to_sj (parent_join=0x7fffe0018568, subq_pred=0x7fffe005a8a8) at /home/sanja/maria/git/server/sql/opt_subselect.cc:1643
#5  0x0000000000764113 in convert_join_subqueries_to_semijoins (join=0x7fffe0018568) at /home/sanja/maria/git/server/sql/opt_subselect.cc:1122
#6  0x00000000006421c2 in JOIN::optimize (this=0x7fffe0018568) at /home/sanja/maria/git/server/sql/sql_select.cc:1011
#7  0x00000000006031ea in st_select_lex::optimize_unflattened_subqueries (this=0x7fffe0016178, const_only=false) at /home/sanja/maria/git/server/sql/sql_lex.cc:3530
#8  0x000000000076dc64 in JOIN::optimize_unflattened_subqueries (this=0x7fffe0051bd8) at /home/sanja/maria/git/server/sql/opt_subselect.cc:4973
#9  0x0000000000644a44 in JOIN::optimize (this=0x7fffe0051bd8) at /home/sanja/maria/git/server/sql/sql_select.cc:1665
#10 0x0000000000649f13 in mysql_select (thd=0x1f3d350, rref_pointer_array=0x7fffe0016438, tables=0x7fffe005c638, wild_num=0, fields=..., conds=0x0, og_num=0, order=0x0, group=0x0, having=0x7fffe0018b58, proc_param=0x0, select_options=2416184064, result=0x7fffe004f868, unit=0x7fffe0015a78, select_lex=0x7fffe0016178) at /home/sanja/maria/git/server/sql/sql_select.cc:3080
#11 0x000000000063ffc3 in handle_select (thd=0x1f3d350, lex=0x7fffe00159c8, result=0x7fffe004f868, setup_tables_done_option=0) at /home/sanja/maria/git/server/sql/sql_select.cc:319
#12 0x00000000006157b2 in execute_sqlcom_select (thd=0x1f3d350, all_tables=0x7fffe005c638) at /home/sanja/maria/git/server/sql/sql_parse.cc:4689
#13 0x000000000060e241 in mysql_execute_command (thd=0x1f3d350) at /home/sanja/maria/git/server/sql/sql_parse.cc:2234
#14 0x0000000000631c91 in Prepared_statement::execute (this=0x7fffe00463a0, expanded_query=0x7ffff41cdc40, open_cursor=false) at /home/sanja/maria/git/server/sql/sql_prepare.cc:3930
#15 0x0000000000630c94 in Prepared_statement::execute_loop (this=0x7fffe00463a0, expanded_query=0x7ffff41cdc40, open_cursor=false, packet=0x0, packet_end=0x0) at /home/sanja/maria/git/server/sql/sql_prepare.cc:3589
#16 0x000000000062ebbb in mysql_sql_stmt_execute (thd=0x1f3d350) at /home/sanja/maria/git/server/sql/sql_prepare.cc:2738
#17 0x000000000060e272 in mysql_execute_command (thd=0x1f3d350) at /home/sanja/maria/git/server/sql/sql_parse.cc:2244
#18 0x000000000061861c in mysql_parse (thd=0x1f3d350, rawbuf=0x7fffe005c088 "EXECUTE stmt", length=12, parser_state=0x7ffff41ce6a0) at /home/sanja/maria/git/server/sql/sql_parse.cc:5914

i.e. there is call fix_after_pullot for Item_ref which is in HAVING and it is right that it is Item_ref because after in the moment of execution HAVING it can refer to temporary table already. but Item_ref calls (I doubts that it is correct) fix_after_pullout for field of outer most select which was not pullout and can't be pullout.

Comment by Oleksandr Byelkin [ 2015-12-03 ]

Above if first catch of Item_field::fix_after_pullout on this test suite.

Comment by Elena Stepanova [ 2016-05-29 ]

See also MDEV-10148

Comment by Elena Stepanova [ 2016-08-28 ]

I have to disable the whole "2nd execution" vector in my tests because of this, effective immediately.
It's a huge limitation of test coverage, but otherwise running them is meaningless, they just crash before there is a chance to hit anything else.

Comment by Sergei Petrunia [ 2016-08-29 ]

The "Alternative testcase" crashes current 10.1 (2d65679384c36ae2e46b2f62538223c3d71fb00a)
with a different stack trace:

 
  #0  0x000055555599f58e in Query_arena::alloc (this=0xa5a5a5a5a5a5a5bd, size=8) at /home/psergey/dev-git/10.1-dbg8/sql/sql_class.h:939
  #1  0x0000555555ac9d60 in print_join (thd=0xa5a5a5a5a5a5a5a5, eliminated_tables=0, str=0x7ffff42fdce0, tables=0x7fff5c007e18, query_type=QT_ORDINARY) at /home/psergey/dev-git/10.1-dbg8/sql/sql_select.cc:24862
  #2  0x0000555555acabe9 in st_select_lex::print (this=0x7fff5c007ca0, thd=0xa5a5a5a5a5a5a5a5, str=0x7ffff42fdce0, query_type=QT_ORDINARY) at /home/psergey/dev-git/10.1-dbg8/sql/sql_select.cc:25159
  #3  0x0000555555d386da in subselect_single_select_engine::print (this=0x7fff5c00a440, str=0x7ffff42fdce0, query_type=QT_ORDINARY) at /home/psergey/dev-git/10.1-dbg8/sql/item_subselect.cc:4291
  #4  0x0000555555d2e6ac in Item_subselect::print (this=0x7fff5c00a2f0, str=0x7ffff42fdce0, query_type=QT_ORDINARY) at /home/psergey/dev-git/10.1-dbg8/sql/item_subselect.cc:955
  #5  0x0000555555d2fd79 in Item_exists_subselect::print (this=0x7fff5c00a2f0, str=0x7ffff42fdce0, query_type=QT_ORDINARY) at /home/psergey/dev-git/10.1-dbg8/sql/item_subselect.cc:1403
  #6  0x0000555555b19a64 in print_where (cond=0x7fff5c00a2f0, info=0x55555639337c "WHERE in setup_conds", query_type=QT_ORDINARY) at /home/psergey/dev-git/10.1-dbg8/sql/sql_test.cc:67
  #7  0x00005555559f6422 in setup_conds (thd=0x555557dd1b10, tables=0x7fff5c007698, leaves=..., conds=0x7fff5c00b188) at /home/psergey/dev-git/10.1-dbg8/sql/sql_base.cc:8618
  #8  0x0000555555ad2f3b in setup_without_group (thd=0x555557dd1b10, ref_pointer_array=0x7fff5c00b3d0, tables=0x7fff5c007698, leaves=..., fields=..., all_fields=..., conds=0x7fff5c00b188, order=0x0, group=0x0, hidden_group_fields=0x7fff5c00b068, reserved=0x555557dd5ec4) at /home/psergey/dev-git/10.1-dbg8/sql/sql_select.cc:645
  #9  0x0000555555a8c15b in JOIN::prepare (this=0x7fff5c00ad40, rref_pointer_array=0x555557dd5ea0, tables_init=0x7fff5c007698, wild_num=1, conds_init=0x7fff5c00a2f0, og_num=0, order_init=0x0, skip_order_by=false, group_init=0x0, having_init=0x0, proc_param_init=0x0, select_lex_arg=0x555557dd5c28, unit_arg=0x555557dd5528) at /home/psergey/dev-git/10.1-dbg8/sql/sql_select.cc:799
  #10 0x0000555555a956fe in mysql_select (thd=0x555557dd1b10, rref_pointer_array=0x555557dd5ea0, tables=0x7fff5c007698, wild_num=1, fields=..., conds=0x7fff5c00a2f0, og_num=0, order=0x0, group=0x0, having=0x0, proc_param=0x0, select_options=2147748608, result=0x7fff5c00ad20, unit=0x555557dd5528, select_lex=0x555557dd5c28) at /home/psergey/dev-git/10.1-dbg8/sql/sql_select.cc:3415
  #11 0x0000555555a8b341 in handle_select (thd=0x555557dd1b10, lex=0x555557dd5460, result=0x7fff5c00ad20, setup_tables_done_option=0) at /home/psergey/dev-git/10.1-dbg8/sql/sql_select.cc:384
  #12 0x0000555555a5b861 in execute_sqlcom_select (thd=0x555557dd1b10, all_tables=0x7fff5c007698) at /home/psergey/dev-git/10.1-dbg8/sql/sql_parse.cc:5894
  #13 0x0000555555a51521 in mysql_execute_command (thd=0x555557dd1b10) at /home/psergey/dev-git/10.1-dbg8/sql/sql_parse.cc:2960
  #14 0x0000555555a5efb1 in mysql_parse (thd=0x555557dd1b10, rawbuf=0x7fff5c007408 "SELECT * FROM t AS t1\nWHERE EXISTS ( \n  SELECT * FROM t AS t2 WHERE t1.i IN ( \n    SELECT i FROM t \n  ) \n)", length=106, parser_state=0x7ffff42ff4f0) at /home/psergey/dev-git/10.1-dbg8/sql/sql_parse.cc:7314

If I remove the prepared statement part and just run the query, it also crashes at the same place.

Comment by Sergei Petrunia [ 2016-08-29 ]

Discussed the issue with sanja.

The issue is related to MDEV-8833, for which a patch is waiting for my review. We should deal with MDEV-8833 first in order to avoid investigating the same issue over and over.

Comment by Sergei Petrunia [ 2016-09-02 ]

Tried the (not pushed yet) fix for MDEV-8833 on a 10.2 tree. The "Alternative test case" now works, but the first test case still fails with the same stack trace as in the report.

Comment by Elena Stepanova [ 2016-09-25 ]

What's up with this issue? Is it supposed to be fixed in any versions?
I keep getting the same assertion failure in different circumstances, unless I know that this one is fixed, I can't tell whether the other appearances indicate a new problem, or they are duplicates.

Comment by Oleksandr Byelkin [ 2016-11-08 ]

In the first case incorrect context of the item:
(gdb) print dbug_print_select(context->select_lex)
$1 = 0x55555707b160 <dbug_item_print_buf> "select a from test.t1 semi join (test.t1) where (1 and (b = a) and (a = a))"
(gdb) print dbug_print_item(this)
$2 = 0x55555707b160 <dbug_item_print_buf> "t2.b"

i.e. t2.b is from sub-select but context points already on the top select (probably because it was moved to semi-join) and so it can't be "outer" field, but we trying resolve it as outer.

Comment by Oleksandr Byelkin [ 2016-11-08 ]

Second case is the same:
(gdb) p dbug_print_item(this)
$1 = 0x55555707b160 <dbug_item_print_buf> "t1.i"
(gdb) p dbug_print_select(context->select_lex)
$2 = 0x55555707b160 <dbug_item_print_buf> "select 1 from test.t t2 semi join (test.t) where (1 and (t1.i = i))"
(gdb)

Comment by Sergei Petrunia [ 2016-12-15 ]

Modified it a bit to make it unambigous:

CREATE TABLE t1a (a1 INT) ENGINE=MyISAM;
insert into t1a select * from t1;

PREPARE stmt FROM "
SELECT * FROM t2
HAVING 0 IN ( 
  SELECT a FROM t1 
  WHERE a IN ( 
    SELECT a1 FROM t1a
    WHERE b = a1
  )
)
"; 
 
EXECUTE stmt;
EXECUTE stmt;

Debugging PREPARE, I reach where item_field->fix_fields() is called for the Item_field object that represents reference to 'b' in 'b=a1'.

The Item_field this=0x7fff7505eb10 is substituted to an Item_ref
(0x7fff750463d0)

Item_ref->ref points to top-level JOIN's field_list->elem(0), which is the same as top-level select_lex->item_list.elem(0), which is the same as top-level's join->ref_pointer_array[0], which is an Item_field object at 0x7fff750608b8.

Good so far.

Debugging the first EXECUTE, I can see Item_field::fix_fields() called for the Item_field object that represents reference to 'b' in 'b=a1' (this=0x7fff7505eb10).

Again, the Item_field is substituted with an Item_ref (0x7fff75046230). Which points to the same Item_field from the top-level join, 0x7fff750608b8.

Things get interesting when we enter convert_subq_to_sj() and reach this line:

  sj_nest->sj_on_expr->fix_after_pullout(parent_lex, &sj_nest->sj_on_expr);

Item_ref::fix_after_pullout(this=0x7fff75046230) calls Item_field::fix_after_pullout (this=0x7fff750608b8). This for the object from the top-level JOIN!
The Item_field gets a new Name_resolution_context object ($CTX)

Comment by Sergei Petrunia [ 2016-12-15 ]

Second EXECUTE starts.
Top-level join calls Item_field::fix_fields (this=0x7fff750608b8)
It has $CTX as Name_resolution_context object.
$CTX points to the table 't2', but it has context->select_lex->select_number==2 (this is where the subquery was merged into).

Which causes is_outer_table(table_list, context->select_lex)== true, which causes fix_outer_field() to be invoked
which fails the assert.

Comment by Sergei Petrunia [ 2016-12-15 ]

Looking at the context object:

(gdb) p context->outer_context
  $372 = (Name_resolution_context *) 0x0
(gdb) p context->select_lex->select_number
  $373 = 2
(gdb) p context->first_name_resolution_table->alias
  $375 = 0x7fff7505b638 "t2"
(gdb) p context->last_name_resolution_table
  $376 = (TABLE_LIST *) 0x0

So it points at select#2 (wrong), it has outer_context=NULL (wrong if pointing at select#2 is correct). It points at the correct table.

Comment by Sergei Petrunia [ 2016-12-16 ]

This patch makes the testcases pass:
https://gist.github.com/spetrunia/c4e1a40d0d36369323dc8cc02ec98500

Need to discuss it with sanja.

Comment by Sergei Petrunia [ 2016-12-16 ]

Sanja please review

Comment by Oleksandr Byelkin [ 2016-12-19 ]

OK to push

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