Server crashes in different ways while executing concurrent flow involving views and non-empty sql_mode (MDEV-7601)

[MDEV-7581] Server crashes in st_select_lex_unit::cleanup after a sequence of statements Created: 2015-02-13  Updated: 2015-12-02  Resolved: 2015-05-19

Status: Closed
Project: MariaDB Server
Component/s: Data Definition - Procedure, Optimizer
Affects Version/s: 5.5
Fix Version/s: 5.5.45, 10.0.21

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


 Description   

Note: The test case is strange and fragile, contains some seemingly unrelated statements and structures; I removed everything I could, but the rest seems necessary, at least for reproducing the problem on my builds. So, while the current test case doesn't crash on 10.0 build, I think it's still likely that the problem present there as well, so I'm setting Fix Version to 10.0 as well – please update it if you find out that it's a 5.5-only bug.

Stack trace from 5.5 revno 4433

#3  <signal handler called>
#4  0x00000000006e67f1 in st_select_lex_unit::cleanup (this=0x7f371e9d3128) at 5.5/sql/sql_union.cc:887
#5  0x000000000069945d in free_underlaid_joins (thd=0x7f371f950060, select=0x7f371f953a60) at 5.5/sql/sql_select.cc:21825
#6  0x0000000000618acd in mysql_insert (thd=0x7f371f950060, table_list=0x7f371ea87190, fields=..., values_list=..., update_fields=..., update_values=..., duplic=DUP_ERROR, ignore=false) at 5.5/sql/sql_insert.cc:992
#7  0x0000000000636ef1 in mysql_execute_command (thd=0x7f371f950060) at 5.5/sql/sql_parse.cc:2974
#8  0x000000000063ec8e in mysql_parse (thd=0x7f371f950060, rawbuf=0x7f371ea87078 "INSERT INTO `view_AA` ( `i` ) VALUES (3)", length=40, parser_state=0x7f371f3b5620) at 5.5/sql/sql_parse.cc:5909
#9  0x00000000006328d1 in dispatch_command (command=COM_QUERY, thd=0x7f371f950060, packet=0x7f371fa07061 "INSERT INTO `view_AA` ( `i` ) VALUES (3)", packet_length=40) at 5.5/sql/sql_parse.cc:1079
#10 0x0000000000631a5d in do_command (thd=0x7f371f950060) at 5.5/sql/sql_parse.cc:793
#11 0x00000000007340ea in do_handle_one_connection (thd_arg=0x7f371f950060) at 5.5/sql/sql_connect.cc:1266
#12 0x0000000000733ba9 in handle_one_connection (arg=0x7f371f950060) at 5.5/sql/sql_connect.cc:1181
#13 0x0000000000b6c2cd in pfs_spawn_thread (arg=0x7f371f971ca0) at 5.5/storage/perfschema/pfs.cc:1015
#14 0x00007f3725b44b50 in start_thread (arg=<optimized out>) at pthread_create.c:304
#15 0x00007f3723dfa70d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112

Test case

SET sql_mode = ONLY_FULL_GROUP_BY;
 
CREATE TABLE A (
 i INT,
 i1 INT,
 i2 INT,
 d1 DATE,
 d2 DATE,
 col_time_nokey1 TIME,
 col_time_nokey2 TIME,
 col_datetime_nokey1 DATETIME,
 col_datetime_nokey2 DATETIME,
 col_varchar_nokey1 VARCHAR(1),
 col_varchar_nokey2 VARCHAR(1)
) ENGINE=MyISAM;
 
CREATE VIEW view_A AS SELECT * FROM A;
 
CREATE TABLE B (
 col_varchar_nokey VARCHAR(1)
) ENGINE=MyISAM;
 
CREATE TABLE AA (
 i INT,
 i1 INT,
 i2 INT,
 d1 DATE,
 d2 DATE,
 col_time_nokey1 TIME,
 col_time_nokey2 TIME,
 col_datetime_nokey1 DATETIME,
 col_datetime_nokey2 DATETIME,
 col_varchar_nokey1 VARCHAR(1),
 col_varchar_nokey2 VARCHAR(1)
) ENGINE=MyISAM;
 
CREATE VIEW view_AA AS SELECT * FROM AA;
 
CREATE TABLE DD (
 i INT,
 i1 INT,
 i2 INT,
 d1 DATE,
 d2 DATE,
 col_time_nokey1 TIME,
 col_time_nokey2 TIME,
 col_datetime_nokey1 DATETIME,
 col_datetime_nokey2 DATETIME,
 col_varchar_nokey1 VARCHAR(1),
 col_varchar_nokey2 VARCHAR(1)
) ENGINE=MyISAM;
 
CREATE VIEW view_DD AS SELECT * FROM DD;
 
CREATE TRIGGER tr1 BEFORE INSERT ON `AA` FOR EACH ROW INSERT INTO `view_A` SELECT * FROM `view_AA` LIMIT 0 ; 
CREATE TRIGGER tr2 BEFORE INSERT ON `B` FOR EACH ROW INSERT INTO `D` SELECT * FROM `A` LIMIT 0 ; 
 
INSERT INTO `view_AA` ( `i` ) VALUES (1);
INSERT INTO `AA` ( `i` ) VALUES (2);
DELETE FROM `B`;
INSERT INTO `view_DD` ( `i` ) VALUES (1);
INSERT INTO `view_AA` ( `i` ) VALUES (3);

cmake . -DCMAKE_BUILD_TYPE=Debug && make



 Comments   
Comment by Elena Stepanova [ 2015-02-15 ]

See also MDEV-7590, might be related.

Comment by Michael Widenius [ 2015-05-19 ]

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.

Fix pushed into the 5.5 tree.

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