[MDEV-32164] Server crashes in JOIN::cleanup after erroneous query with view - Jira

Details

Type: Bug
Status: Closed (View Workflow)
Priority: Blocker
Resolution: Fixed
Affects Version/s: 10.6, 10.10(EOL)
Fix Version/s: 10.6.16, 10.11.6
Component/s: Optimizer
Labels:
- regression

Description

--source include/have_innodb.inc

CREATE TABLE t1 (a INT, b INT, KEY (a,b)) ENGINE=InnoDB;

CREATE VIEW v1 AS SELECT a FROM t1 WHERE a != '' GROUP BY a;

INSERT INTO t1 VALUES (1,NULL),(2,0),(3,NULL);

CREATE TABLE t2 (c INT) ENGINE=InnoDB;

--error ER_TRUNCATED_WRONG_VALUE

CREATE TEMPORARY TABLE tmp SELECT v1.a FROM v1 JOIN t2 ON (v1.a = t2.c);

# Cleanup

DROP VIEW v1;

DROP TABLE t1, t2;

10.6 961b96a5
#3 <signal handler called>
#4 0x0000563905865246 in next_breadth_first_tab (first_top_tab=0x629000314008, n_top_tabs_count=2, tab=0x629000314008) at /data/src/10.6/sql/sql_select.cc:10862
#5 0x0000563905881ac3 in JOIN::cleanup (this=0x62900030d988, full=true) at /data/src/10.6/sql/sql_select.cc:14801
#6 0x000056390583b0ae in JOIN::destroy (this=0x62900030d988) at /data/src/10.6/sql/sql_select.cc:4863
#7 0x0000563905a6437b in st_select_lex::cleanup (this=0x62b0000c4ad8) at /data/src/10.6/sql/sql_union.cc:2802
#8 0x000056390583c6ed in mysql_select (thd=0x62b0000bd218, tables=0x62b0000c5148, fields=..., conds=0x0, og_num=0, order=0x0, group=0x0, having=0x0, proc_param=0x0, select_options=2201171004160, result=0x62900030d838, unit=0x62b0000c15c0, select_lex=0x62b0000c4ad8) at /data/src/10.6/sql/sql_select.cc:5110
#9 0x000056390580be32 in handle_select (thd=0x62b0000bd218, lex=0x62b0000c14f8, result=0x62900030d838, setup_tables_done_option=0) at /data/src/10.6/sql/sql_select.cc:559
#10 0x0000563905a21d47 in Sql_cmd_create_table_like::execute (this=0x62b0000c4330, thd=0x62b0000bd218) at /data/src/10.6/sql/sql_table.cc:11915
#11 0x000056390576e2d4 in mysql_execute_command (thd=0x62b0000bd218, is_called_from_prepared_stmt=false) at /data/src/10.6/sql/sql_parse.cc:6024
#12 0x000056390577b6fb in mysql_parse (thd=0x62b0000bd218, rawbuf=0x62b0000c4238 "CREATE TEMPORARY TABLE tmp SELECT v1.a FROM v1 JOIN t2 ON (v1.a = t2.c)", length=71, parser_state=0x7f8a502539f0) at /data/src/10.6/sql/sql_parse.cc:8048
#13 0x00005639057513bc in dispatch_command (command=COM_QUERY, thd=0x62b0000bd218, packet=0x629000280219 "CREATE TEMPORARY TABLE tmp SELECT v1.a FROM v1 JOIN t2 ON (v1.a = t2.c)", packet_length=71, blocking=true) at /data/src/10.6/sql/sql_parse.cc:1896
#14 0x000056390574e0f0 in do_command (thd=0x62b0000bd218, blocking=true) at /data/src/10.6/sql/sql_parse.cc:1409
#15 0x0000563905bbabe4 in do_handle_one_connection (connect=0x608000003938, put_in_cache=true) at /data/src/10.6/sql/sql_connect.cc:1416
#16 0x0000563905bba5a5 in handle_one_connection (arg=0x6080000038b8) at /data/src/10.6/sql/sql_connect.cc:1318
#17 0x0000563906817316 in pfs_spawn_thread (arg=0x617000008218) at /data/src/10.6/storage/perfschema/pfs.cc:2201
#18 0x00007f8a5e8a7fd4 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:442
#19 0x00007f8a5e9285bc in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81

Another frequently seen stack trace on similar test cases

#3  <signal handler called>

#4  0x000055c3b8ac555e in SQL_SELECT::cleanup (this=0xbebebebebebebebe) at /data/src/10.6/sql/opt_range.cc:1246

#5  0x000055c3b8ac5726 in SQL_SELECT::~SQL_SELECT (this=0xbebebebebebebebe, __in_chrg=<optimized out>) at /data/src/10.6/sql/opt_range.cc:1260

#6  0x000055c3b7f95084 in st_join_table::cleanup (this=0x6290003b6238) at /data/src/10.6/sql/sql_select.cc:14342

#7  0x000055c3b7f989ca in JOIN::cleanup (this=0x6290003af898, full=true) at /data/src/10.6/sql/sql_select.cc:14804

#8  0x000055c3b7f520ae in JOIN::destroy (this=0x6290003af898) at /data/src/10.6/sql/sql_select.cc:4863

#9  0x000055c3b817b37b in st_select_lex::cleanup (this=0x62b0000c4c68) at /data/src/10.6/sql/sql_union.cc:2802

#10 0x000055c3b7f536ed in mysql_select (thd=0x62b0000bd218, tables=0x62b0000c8150, fields=..., conds=0x0, og_num=0, order=0x0, group=0x0, having=0x0, proc_param=0x0, select_options=2202244745984, result=0x6290003af7d0, unit=0x62b0000c15c0, select_lex=0x62b0000c4c68) at /data/src/10.6/sql/sql_select.cc:5110

#11 0x000055c3b7f22e32 in handle_select (thd=0x62b0000bd218, lex=0x62b0000c14f8, result=0x6290003af7d0, setup_tables_done_option=1073741824) at /data/src/10.6/sql/sql_select.cc:559

#12 0x000055c3b7e7b6c3 in mysql_execute_command (thd=0x62b0000bd218, is_called_from_prepared_stmt=false) at /data/src/10.6/sql/sql_parse.cc:4729

#13 0x000055c3b7e926fb in mysql_parse (thd=0x62b0000bd218, rawbuf=0x62b0000c4238 "REPLACE INTO tmp_ExecuteAsInsertReturning_32430 SELECT field1, field2, field3, field4 FROM (SELECT a2.field1 AS field1, a2.field2 AS field2, a2.field3 AS field3, a2.field4 AS field4 FROM view5 AS a1 J"..., length=250, parser_state=0x7f901e63b9f0) at /data/src/10.6/sql/sql_parse.cc:8048

#14 0x000055c3b7e683bc in dispatch_command (command=COM_QUERY, thd=0x62b0000bd218, packet=0x629000280219 "REPLACE INTO tmp_ExecuteAsInsertReturning_32430 SELECT field1, field2, field3, field4 FROM (SELECT a2.field1 AS field1, a2.field2 AS field2, a2.field3 AS field3, a2.field4 AS field4 FROM view5 AS a1 J"..., packet_length=250, blocking=true) at /data/src/10.6/sql/sql_parse.cc:1896

#15 0x000055c3b7e650f0 in do_command (thd=0x62b0000bd218, blocking=true) at /data/src/10.6/sql/sql_parse.cc:1409

#16 0x000055c3b82d1be4 in do_handle_one_connection (connect=0x6080000033b8, put_in_cache=true) at /data/src/10.6/sql/sql_connect.cc:1416

#17 0x000055c3b82d15a5 in handle_one_connection (arg=0x608000003338) at /data/src/10.6/sql/sql_connect.cc:1318

#18 0x000055c3b8f2e316 in pfs_spawn_thread (arg=0x617000008218) at /data/src/10.6/storage/perfschema/pfs.cc:2201

#19 0x00007f90300a7fd4 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:442

#20 0x00007f90301285bc in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81

The failure started happening after this commit in 10.6

commit ca5c122adcd39c34b1bd7059903668586496caf6

Author: Monty

Date:   Fri Aug 11 17:59:40 2023 +0300

    MDEV-9938 Prepared statement return wrong result (missing row)

Attachments

Activity

Ascending order - Click to sort in descending order

Michael Widenius added a comment - 2023-09-27 16:32

The problem was that we did not handle errors properly in
JOIN::get_best_combination. In case an early error, JOIN->join_tab would
contain uninitialized values, which would cause errors on cleanup().

The error in question was reported earlier, but not noticed until later.
One cause of this is that most of the sql_select.cc code just checks
thd->fatal_error and not thd->is_error().
Fixed by changing of checks of fatal_error to is_error() and fixing cleanup of JOIN::get_best_combination()

Michael Widenius added a comment - 2023-09-27 16:32 The problem was that we did not handle errors properly in JOIN::get_best_combination. In case an early error, JOIN->join_tab would contain uninitialized values, which would cause errors on cleanup(). The error in question was reported earlier, but not noticed until later. One cause of this is that most of the sql_select.cc code just checks thd->fatal_error and not thd->is_error(). Fixed by changing of checks of fatal_error to is_error() and fixing cleanup of JOIN::get_best_combination()

Michael Widenius added a comment - 2023-10-07 14:30

The problem was that we did not handle errors properly in
JOIN::get_best_combination. In case an early error, JOIN->join_tab would
contain uninitialized values, which would cause errors on cleanup().

The error in question was reported earlier, but not noticed until later.
One cause of this is that most of the sql_select.cc code just checks
thd->fatal_error and not thd->is_error().
Fixed by changing of checks of fatal_error to is_error().

Michael Widenius added a comment - 2023-10-07 14:30 The problem was that we did not handle errors properly in JOIN::get_best_combination. In case an early error, JOIN->join_tab would contain uninitialized values, which would cause errors on cleanup(). The error in question was reported earlier, but not noticed until later. One cause of this is that most of the sql_select.cc code just checks thd->fatal_error and not thd->is_error(). Fixed by changing of checks of fatal_error to is_error().

MariaDB Server

Server crashes in JOIN::cleanup after erroneous query with view

Details

Description

Attachments

Activity

People

Dates

Git Integration