[MDEV-16512] Server crashes in find_field_in_table_ref on 2nd execution of SP referring to non-existing field Created: 2018-06-18  Updated: 2018-06-27  Resolved: 2018-06-27

Status: Closed
Project: MariaDB Server
Component/s: Stored routines
Affects Version/s: 5.5, 10.0, 10.1, 10.2, 10.3
Fix Version/s: 5.5.61, 10.0.36, 10.1.35, 10.2.17, 10.3.8

Type: Bug Priority: Major
Reporter: Elena Stepanova Assignee: Michael Widenius
Resolution: Fixed Votes: 0
Labels: None


 Description   

CREATE TABLE t (i INT);
CREATE PROCEDURE p() SELECT t1.f FROM t AS t1 JOIN t AS t2 USING (f);
--error ER_BAD_FIELD_ERROR
CALL p;
--error ER_BAD_FIELD_ERROR
CALL p;
 
# Cleanup
DROP PROCEDURE p;
DROP TABLE t;

5.5 e425216045c

#3  <signal handler called>
#4  0x00000000005a9ae9 in find_field_in_table_ref (thd=0x7f2bfe664060, table_list=0xa5a5a5a5a5a5a5a5, name=0x7f2bfd599d48 "f", length=1, item_name=0x7f2bfd599d48 "f", db_name=0x0, table_name=0x7f2bfd599d38 "t1", ref=0x7f2bfd599e68, check_privileges=true, allow_rowid=true, cached_field_index_ptr=0x7f2bfd599e1c, register_tree_change=true, actual_table=0x7f2c043457d8) at /data/src/5.5/sql/sql_base.cc:6628
#5  0x00000000005aa809 in find_field_in_tables (thd=0x7f2bfe664060, item=0x7f2bfd599d58, first_table=0xa5a5a5a5a5a5a5a5, last_table=0x0, ref=0x7f2bfd599e68, report_error=IGNORE_EXCEPT_NON_UNIQUE, check_privileges=true, register_tree_change=true) at /data/src/5.5/sql/sql_base.cc:6980
#6  0x00000000007ca82e in Item_field::fix_fields (this=0x7f2bfd599d58, thd=0x7f2bfe664060, reference=0x7f2bfd599e68) at /data/src/5.5/sql/item.cc:5260
#7  0x00000000005ad1b9 in setup_fields (thd=0x7f2bfe664060, ref_pointer_array=0x7f2bfd581708, fields=..., mark_used_columns=MARK_COLUMNS_READ, sum_func_list=0x7f2bfd578520, pre_fix=0x7f2bfd599298, allow_sum_func=true) at /data/src/5.5/sql/sql_base.cc:8192
#8  0x000000000062f31f in JOIN::prepare (this=0x7f2bfd5781d0, rref_pointer_array=0x7f2bfd599408, tables_init=0x7f2bfd580078, wild_num=0, 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=0x7f2bfd599168, unit_arg=0x7f2bfd598a88) at /data/src/5.5/sql/sql_select.cc:733
#9  0x0000000000637d0a in mysql_select (thd=0x7f2bfe664060, rref_pointer_array=0x7f2bfd599408, tables=0x7f2bfd580078, wild_num=0, fields=..., conds=0x0, og_num=0, order=0x0, group=0x0, having=0x0, proc_param=0x0, select_options=2147749632, result=0x7f2bfd5781b0, unit=0x7f2bfd598a88, select_lex=0x7f2bfd599168) at /data/src/5.5/sql/sql_select.cc:3106
#10 0x000000000062e51a in handle_select (thd=0x7f2bfe664060, lex=0x7f2bfd5989d8, result=0x7f2bfd5781b0, setup_tables_done_option=0) at /data/src/5.5/sql/sql_select.cc:323
#11 0x0000000000607932 in execute_sqlcom_select (thd=0x7f2bfe664060, all_tables=0x7f2bfd580078) at /data/src/5.5/sql/sql_parse.cc:4678
#12 0x0000000000600cb3 in mysql_execute_command (thd=0x7f2bfe664060) at /data/src/5.5/sql/sql_parse.cc:2224
#13 0x00000000008e1f10 in sp_instr_stmt::exec_core (this=0x7f2bfd599fc8, thd=0x7f2bfe664060, nextp=0x7f2c04346c28) at /data/src/5.5/sql/sp_head.cc:3220
#14 0x00000000008e16b7 in sp_lex_keeper::reset_lex_and_exec_core (this=0x7f2bfd59a008, thd=0x7f2bfe664060, nextp=0x7f2c04346c28, open_tables=false, instr=0x7f2bfd599fc8) at /data/src/5.5/sql/sp_head.cc:2998
#15 0x00000000008e1c38 in sp_instr_stmt::execute (this=0x7f2bfd599fc8, thd=0x7f2bfe664060, nextp=0x7f2c04346c28) at /data/src/5.5/sql/sp_head.cc:3144
#16 0x00000000008ddaa1 in sp_head::execute (this=0x7f2bfd598078, thd=0x7f2bfe664060, merge_da_on_success=true) at /data/src/5.5/sql/sp_head.cc:1431
#17 0x00000000008df807 in sp_head::execute_procedure (this=0x7f2bfd598078, thd=0x7f2bfe664060, args=0x7f2bfe668020) at /data/src/5.5/sql/sp_head.cc:2197
#18 0x0000000000605f8f in mysql_execute_command (thd=0x7f2bfe664060) at /data/src/5.5/sql/sql_parse.cc:4115
#19 0x000000000060a4fe in mysql_parse (thd=0x7f2bfe664060, rawbuf=0x7f2bfd548078 "CALL p", length=6, parser_state=0x7f2c04347640) at /data/src/5.5/sql/sql_parse.cc:5923
#20 0x00000000005fe213 in dispatch_command (command=COM_QUERY, thd=0x7f2bfe664060, packet=0x7f2c0235b061 "CALL p", packet_length=6) at /data/src/5.5/sql/sql_parse.cc:1066
#21 0x00000000005fd405 in do_command (thd=0x7f2bfe664060) at /data/src/5.5/sql/sql_parse.cc:793
#22 0x0000000000700677 in do_handle_one_connection (thd_arg=0x7f2bfe664060) at /data/src/5.5/sql/sql_connect.cc:1268
#23 0x0000000000700404 in handle_one_connection (arg=0x7f2bfe664060) at /data/src/5.5/sql/sql_connect.cc:1184
#24 0x0000000000a0f939 in pfs_spawn_thread (arg=0x7f2bff3933a0) at /data/src/5.5/storage/perfschema/pfs.cc:1015
#25 0x00007f2c03f7a494 in start_thread (arg=0x7f2c04348700) at pthread_create.c:333
#26 0x00007f2c0299093f in clone () from /lib/x86_64-linux-gnu/libc.so.6



 Comments   
Comment by Michael Widenius [ 2018-06-27 ]

Problem was in the natural join code that it changed TABLE_LIST and
Item_fields but didn't restore changed things if things goes wrong
and was not able to re-execute after failure.
Some of the problems could have been avoided if we would have run
fix_fields before doing natural join transformations.

Fixed by marking functions complete AFTER they had executed, instead of at start.
I had also to change some tests that checked if Item_fields are usable.

This doesn't fix all known problems, but at least avoids some crashes.
What should be done in the near future is to mark the statement in the SP
as 'not re-executable' and force a reparse of it on next execution.

Comment by Michael Widenius [ 2018-06-27 ]

Pushed into 5.5

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