[MDEV-23804] Server crashes in st_select_lex::collect_grouping_fields_for_derived Created: 2020-09-24  Updated: 2023-10-05  Resolved: 2021-01-12

Status: Closed
Project: MariaDB Server
Component/s: Optimizer
Affects Version/s: 10.4, 10.5
Fix Version/s: 10.4.18, 10.5.9

Type: Bug Priority: Major
Reporter: Alice Sherepa Assignee: Varun Gupta (Inactive)
Resolution: Fixed Votes: 0
Labels: regression

Issue Links:
Relates
relates to MDEV-20224 main.derived crashes with ASAN with e... Closed

 Description    

create view v1 AS select database() union values (1),(2);
 
select 1 from v1 where make_set(1, `database()`);

Both debug and non-debug versions are affected.

10.4 a50ce9445844c0bdcf8a

 
Version: '10.4.15-MariaDB-debug-log'  
[ERROR] mysqld got signal 11 ;
 
 
 
Server version: 10.4.15-MariaDB-debug-log
 
 
 
sql/sql_lex.cc:7915(st_select_lex::collect_grouping_fields_for_derived(THD*, st_order*))[0x55fd3ce4d6a1]
 
sql/sql_derived.cc:1478(pushdown_cond_for_derived(THD*, Item*, TABLE_LIST*))[0x55fd3cfcc23d]
 
sql/sql_select.cc:2098(JOIN::optimize_inner())[0x55fd3cfc6d68]
 
sql/sql_select.cc:1615(JOIN::optimize())[0x55fd3cfe74cf]
 
sql/sql_select.cc:4681(mysql_select(THD*, TABLE_LIST*, unsigned int, List<Item>&, Item*, unsigned int, st_order*, st_order*, Item*, st_order*, unsigned long long, select_result*, st_select_lex_unit*, st_select_lex*))[0x55fd3cfb94be]
 
sql/sql_select.cc:410(handle_select(THD*, LEX*, select_result*, unsigned long))[0x55fd3cf2d42b]
 
sql/sql_parse.cc:6355(execute_sqlcom_select(THD*, TABLE_LIST*))[0x55fd3cf1ad85]
 
sql/sql_parse.cc:3889(mysql_execute_command(THD*))[0x55fd3cf364f5]
 
sql/sql_parse.cc:7896(mysql_parse(THD*, char*, unsigned int, Parser_state*, bool, bool))[0x55fd3cf0daf0]
 
sql/sql_parse.cc:1837(dispatch_command(enum_server_command, THD*, char*, unsigned int, bool, bool))[0x55fd3cf0a56f]
 
sql/sql_parse.cc:1352(do_command(THD*))[0x55fd3d2e7141]
 
sql/sql_connect.cc:1412(do_handle_one_connection(CONNECT*))[0x55fd3d2e69e3]
 
sql/sql_connect.cc:1317(handle_one_connection)[0x55fd3e915cf1]
 
nptl/pthread_create.c:487(start_thread)[0x7f03bcdbbfa3]
 
x86_64/clone.S:97(clone)[0x7f03bc3c24cf]
 
 
 
Query (0x62b000062290): select 1 from v1 where make_set(1, `database()`)



 Comments   
Comment by Varun Gupta (Inactive) [ 2020-10-27 ]

Another test case:

CREATE VIEW v1 AS SELECT 3 as a UNION VALUES (1),(2);
 
ANALYZE FORMAT=JSON SELECT * from v1 WHERE a=3;
 
SELECT * from v1 WHERE a=3;

Comment by Varun Gupta (Inactive) [ 2020-10-27 ]

Patch
http://lists.askmonty.org/pipermail/commits/2020-October/014346.html

Comment by Igor Babaev [ 2020-12-29 ]

The problem appeared after the loss of the lines

    if (!sl->cond_pushdown_is_allowed())
 
      continue;

after the commit 

commit d3ff133390231d8224843995af6b11f6a381803e
 
Author: Galina Shalygina <galina.shalygina@mariadb.com>
 
Date:   Tue May 15 23:45:59 2018 +0200
 
    MDEV-12387 Push conditions into materialized subqueries

I don't think it was an intentional loss.
I would recommend to add the test case to 10.3 rather than to 10.4 to avoid another loss of those lines.

Comment by Michael Widenius [ 2021-01-11 ]

I agree with Igor.

Push the test case to 10.3 and the fix to 10.4.

A small suggestion for the patch:

+ if (!sl->cond_pushdown_is_allowed())
+ continue;
Item *extracted_cond_copy;

Move the if() after "Item *extracted_cond_copy"
Two reasons for this:

  • Then we have identical code in 10.3 and 10.4
  • It's better to have first all variable declarations and then the code (to keep declarations and code separated)
Generated at Thu Feb 08 09:25:10 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.