[MDEV-10785] Server crashes in Item_cond::copy_andor_arguments on 2nd execution of PS or SP Created: 2016-09-09  Updated: 2016-09-23  Resolved: 2016-09-23

Status: Closed
Project: MariaDB Server
Component/s: Prepared Statements, Views
Affects Version/s: 10.2
Fix Version/s: 10.2.2

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


 Description   

Note: it might be a duplicate of MDEV-10781, but the stack trace is somewhat different, so I'm filing it separately.
Just like MDEV-10781, the problem started happening after recent merges, but I can't point at the exact commit which caused it.

Stack trace from 10.2 1168e2fa54

#3  <signal handler called>
#4  0x00007f403cb9f2ae in Item_cond::copy_andor_arguments (this=0x7f40314641a0, thd=0x7f4031416070, item=0x7f40315248a0) at /data/src/10.2/sql/item_cmpfunc.cc:4457
#5  0x00007f403cb9f242 in Item_cond_and::copy_andor_structure (this=0x7f40315248a0, thd=0x7f4031416070) at /data/src/10.2/sql/item_cmpfunc.cc:4448
#6  0x00007f403c930385 in reinit_stmt_before_use (thd=0x7f4031416070, lex=0x7f40315d0090) at /data/src/10.2/sql/sql_prepare.cc:2817
#7  0x00007f403c933cbf in Prepared_statement::execute (this=0x7f4031556470, expanded_query=0x7f403d867180, open_cursor=false) at /data/src/10.2/sql/sql_prepare.cc:4256
#8  0x00007f403c932c25 in Prepared_statement::execute_loop (this=0x7f4031556470, expanded_query=0x7f403d867180, open_cursor=false, packet=0x0, packet_end=0x0) at /data/src/10.2/sql/sql_prepare.cc:3912
#9  0x00007f403c930c71 in mysql_sql_stmt_execute (thd=0x7f4031416070) at /data/src/10.2/sql/sql_prepare.cc:3039
#10 0x00007f403c90b79f in mysql_execute_command (thd=0x7f4031416070) at /data/src/10.2/sql/sql_parse.cc:3387
#11 0x00007f403c9190d7 in mysql_parse (thd=0x7f4031416070, rawbuf=0x7f4031464088 "EXECUTE stmt", length=12, parser_state=0x7f403d867dd0, is_com_multi=false, is_next_command=false) at /data/src/10.2/sql/sql_parse.cc:7774
#12 0x00007f403c9074c5 in dispatch_command (command=COM_QUERY, thd=0x7f4031416070, packet=0x7f4031458071 "EXECUTE stmt", packet_length=12, is_com_multi=false, is_next_command=false) at /data/src/10.2/sql/sql_parse.cc:1805
#13 0x00007f403c905ef6 in do_command (thd=0x7f4031416070) at /data/src/10.2/sql/sql_parse.cc:1365
#14 0x00007f403ca417ba in do_handle_one_connection (connect=0x7f403986d410) at /data/src/10.2/sql/sql_connect.cc:1354
#15 0x00007f403ca41547 in handle_one_connection (arg=0x7f403986d410) at /data/src/10.2/sql/sql_connect.cc:1260
#16 0x00007f403cd4fb26 in pfs_spawn_thread (arg=0x7f40398519f0) at /data/src/10.2/storage/perfschema/pfs.cc:1862
#17 0x00007f403bf8a0a4 in start_thread (arg=0x7f403d869300) at pthread_create.c:309
#18 0x00007f403a14287d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111

Test case

CREATE TABLE t1 (i INT);
CREATE OR REPLACE VIEW v1 AS SELECT i FROM t1 WHERE i < 5;
CREATE FUNCTION f (in1 INT) RETURNS INT RETURN in1;
CREATE OR REPLACE ALGORITHM = TEMPTABLE VIEW v2 AS SELECT * FROM v1;
PREPARE stmt FROM "SELECT * FROM v2 WHERE f(0) <> 2";
EXECUTE stmt;
EXECUTE stmt;



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

SELECT_LEX::prep_where was assigned with something which is not in statement memory stored.

Comment by Oleksandr Byelkin [ 2016-09-13 ]

It was created in optimize_cond then somehow to prep_where assigned.

Comment by Oleksandr Byelkin [ 2016-09-13 ]

It is VIEW select and prep_where was assigned only once...

Comment by Oleksandr Byelkin [ 2016-09-13 ]

((f(0) <> 2) and (t1.i < 5))
so (t1.i < 5) pop up after simplify_joins and it was not on statement memory allocated

Comment by Oleksandr Byelkin [ 2016-09-13 ]

Yes f(0) <> 2 was pushed.

Comment by Igor Babaev [ 2016-09-23 ]

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

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