[MDEV-7688] Server crashes in TABLE_LIST::is_view_or_derived on 2nd execution of PS with ONLY_FULL_GROUP_BY Created: 2015-03-10  Updated: 2015-12-02  Resolved: 2015-12-02

Status: Closed
Project: MariaDB Server
Component/s: Optimizer, Prepared Statements, Views
Affects Version/s: 5.5
Fix Version/s: 5.5.45, 10.0.21

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

Issue Links:
Blocks
Relates
relates to MDEV-7689 Server crashes in Item_subselect::rec... Closed
relates to MDEV-7690 Server crashes in Item_field::used_ta... Closed
relates to MDEV-7696 Server goes into an endless loop on 2... Closed
relates to MDEV-7751 Server crashes in TABLE_LIST::reset_c... Closed
relates to MDEV-7689 Server crashes in Item_subselect::rec... Closed
relates to MDEV-7690 Server crashes in Item_field::used_ta... Closed
relates to MDEV-7696 Server goes into an endless loop on 2... Closed
relates to MDEV-7751 Server crashes in TABLE_LIST::reset_c... Closed

 Description   

Attention: I am only getting the crash on a VALGRIND build
cmake . -DCMAKE_BUILD_TYPE=Debug -DWITH_VALGRIND=YES

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

The problem appeared in 5.5 tree with the following revision:

revno: 4255
revision-id: sanja@askmonty.org-20140731071110-4uyuza0ykesfxe1b
parent: monty@mariadb.org-20140730102752-3ilbpvmbhr2r9a4x
committer: sanja@askmonty.org
branch nick: work-maria-5.5-MDEV-6441
timestamp: Thu 2014-07-31 10:11:10 +0300
message:
  MDEV-6441: memory leak
  
  mysql_derived_prepare() was executed on the statement memory.
  Now it is executed on the runtime memory.
  All bugs induced by this were fixed.

Stack trace from 5.5 34f37aa0c0aa87cfb6908500e937516ff37ea6f0

#3  <signal handler called>
#4  0x000000000060fd5a in TABLE_LIST::is_view_or_derived (this=0x2000b0300) at sql/table.h:2083
#5  0x000000000062b3d3 in st_select_lex::update_used_tables (this=0x7f19c3131c18) at sql/sql_lex.cc:3811
#6  0x0000000000665e31 in JOIN::optimize (this=0x7f19c3052618) at sql/sql_select.cc:1003
#7  0x000000000062ac80 in st_select_lex::optimize_unflattened_subqueries (this=0x7f19c31467c8, const_only=true) at sql/sql_lex.cc:3506
#8  0x000000000078305f in JOIN::optimize_constant_subqueries (this=0x7f19c3051a18) at sql/opt_subselect.cc:4973
#9  0x0000000000665ee0 in JOIN::optimize (this=0x7f19c3051a18) at sql/sql_select.cc:1020
#10 0x000000000066d551 in mysql_select (thd=0x7f19c3d18000, rref_pointer_array=0x7f19c3146a88, tables=0x7f19c304f618, wild_num=0, fields=..., conds=0x7f19c307c098, og_num=0, order=0x0, group=0x0, having=0x0, proc_param=0x0, select_options=2416184064, result=0x7f19c3044198, unit=0x7f19c31460c8, select_lex=0x7f19c31467c8) at sql/sql_select.cc:3080
#11 0x0000000000663e63 in handle_select (thd=0x7f19c3d18000, lex=0x7f19c3146018, result=0x7f19c3044198, setup_tables_done_option=0) at sql/sql_select.cc:319
#12 0x000000000063c293 in execute_sqlcom_select (thd=0x7f19c3d18000, all_tables=0x7f19c304f618) at sql/sql_parse.cc:4689
#13 0x000000000063546c in mysql_execute_command (thd=0x7f19c3d18000) at sql/sql_parse.cc:2234
#14 0x0000000000656b1b in Prepared_statement::execute (this=0x7f19c324c280, expanded_query=0x7f19c3bb4c50, open_cursor=false) at sql/sql_prepare.cc:3928
#15 0x0000000000655c32 in Prepared_statement::execute_loop (this=0x7f19c324c280, expanded_query=0x7f19c3bb4c50, open_cursor=false, packet=0x0, packet_end=0x0) at sql/sql_prepare.cc:3587
#16 0x0000000000653d56 in mysql_sql_stmt_execute (thd=0x7f19c3d18000) at sql/sql_prepare.cc:2737
#17 0x000000000063549a in mysql_execute_command (thd=0x7f19c3d18000) at sql/sql_parse.cc:2244
#18 0x000000000063ed98 in mysql_parse (thd=0x7f19c3d18000, rawbuf=0x7f19c301c178 "EXECUTE stmt", length=12, parser_state=0x7f19c3bb5610) at sql/sql_parse.cc:5909
#19 0x00000000006329b3 in dispatch_command (command=COM_QUERY, thd=0x7f19c3d18000, packet=0x7f19c3d8c001 "EXECUTE stmt", packet_length=12) at sql/sql_parse.cc:1079
#20 0x0000000000631b3f in do_command (thd=0x7f19c3d18000) at sql/sql_parse.cc:793
#21 0x0000000000739b14 in do_handle_one_connection (thd_arg=0x7f19c3d18000) at sql/sql_connect.cc:1266
#22 0x00000000007395d3 in handle_one_connection (arg=0x7f19c3d18000) at sql/sql_connect.cc:1181
#23 0x0000000000b836e3 in pfs_spawn_thread (arg=0x7f19c7fed850) at storage/perfschema/pfs.cc:1015
#24 0x00007f19c9e5cb50 in start_thread (arg=<optimized out>) at pthread_create.c:304

Test case

SET sql_mode = ONLY_FULL_GROUP_BY;
 
CREATE TABLE t1 (a INT) ENGINE=MyISAM;
INSERT INTO t1 VALUES (3),(4);
 
CREATE TABLE t2 (b INT) ENGINE=MyISAM;
INSERT INTO t2 VALUES (1),(8);
 
CREATE TABLE t3 (c INT, f1 INT, f2 INT, f3 INT, f4 INT, f5 INT, f6 INT, f7 INT, f8 INT, f9 INT) ENGINE=MyISAM;
CREATE ALGORITHM=MERGE VIEW v3 AS SELECT * FROM t3;
INSERT INTO t3 VALUES (2,4,2,2,2,2,1,1,0,0),(1,6,2,2,1,1,2,2,0,0);
 
CREATE TABLE t4 (d INT) ENGINE=MyISAM;
INSERT INTO t4 VALUES (1),(2);
 
PREPARE stmt FROM "
  SELECT a FROM ( 
    SELECT a FROM t1, t2 WHERE a <> SOME ( SELECT c FROM v3 ) 
  ) AS sq 
  INNER JOIN t2 INNER JOIN t4 ON (d <= b) 
  WHERE EXISTS ( SELECT * FROM t3, t4 ) 
";
 
EXECUTE stmt;
EXECUTE stmt;
 
DROP TABLE t1, t2, t3, t4;



 Comments   
Comment by Oleksandr Byelkin [ 2015-12-02 ]

It looks like fixed

==============================================================================
 
TEST                                      RESULT   TIME (ms) or COMMENT
--------------------------------------------------------------------------
 
worker[1] Using MTR_BUILD_THREAD 300, with reserved ports 16000..16019
SET sql_mode = ONLY_FULL_GROUP_BY;
CREATE TABLE t1 (a INT) ENGINE=MyISAM;
INSERT INTO t1 VALUES (3),(4);
CREATE TABLE t2 (b INT) ENGINE=MyISAM;
INSERT INTO t2 VALUES (1),(8);
CREATE TABLE t3 (c INT, f1 INT, f2 INT, f3 INT, f4 INT, f5 INT, f6 INT, f7 INT, f8 INT, f9 INT) ENGINE=MyISAM;
CREATE ALGORITHM=MERGE VIEW v3 AS SELECT * FROM t3;
INSERT INTO t3 VALUES (2,4,2,2,2,2,1,1,0,0),(1,6,2,2,1,1,2,2,0,0);
CREATE TABLE t4 (d INT) ENGINE=MyISAM;
INSERT INTO t4 VALUES (1),(2);
PREPARE stmt FROM "
  SELECT a FROM ( 
    SELECT a FROM t1, t2 WHERE a <> SOME ( SELECT c FROM v3 ) 
  ) AS sq 
  INNER JOIN t2 INNER JOIN t4 ON (d <= b) 
  WHERE EXISTS ( SELECT * FROM t3, t4 ) 
";
EXECUTE stmt;
a
3
4
3
4
3
4
3
4
3
4
3
4
EXECUTE stmt;
a
3
4
3
4
3
4
3
4
3
4
3
4
drop view v3;
DROP TABLE t1, t2, t3, t4;
main.test                                [ pass ]      7
--------------------------------------------------------------------------
The servers were restarted 0 times
Spent 0.007 of 1 seconds executing testcases
 
Completed: All 1 tests were successful.
 
sanja@Sanja-ThinkPad:~/maria/git/server/mysql-test$ ../sql/mysqld --version../sql/mysqld  Ver 5.5.46-MariaDB-valgrind-max-debug for Linux on x86_64 (Source distribution)
151202 13:33:39 [Note] ../sql/mysqld (mysqld 5.5.46-MariaDB-valgrind-max-debug) starting as process 25726 ...

Comment by Elena Stepanova [ 2015-12-02 ]

Fixed in 5.5.45 / 10.0.21 by the following commit:

commit 2e941fe9fce7f1667993916ff3f238a283286d3f
Author: Monty <monty@mariadb.org>
Date:   Thu Jun 25 23:18:48 2015 +0300
 
    Fixed crashing bug when using ONLY_FULL_GROUP_BY in a stored procedure/trigger that is repeatedly executed.
    This is MDEV-7601, including it's sub tasks MDEV-7594, MDEV-7555, MDEV-7590, MDEV-7581, MDEV-7589
    
    The problem was that select_lex->non_agg_fields was not properly reset for re-execution and this caused an overwrite of a random memory position.
    The fix was move non_agg_fields from select_lext to JOIN, which is properly reset.

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