[MDEV-25565] Crash on 2-nd execution of SP/PS for query calculating window functions from view Created: 2021-04-29  Updated: 2022-07-07  Resolved: 2021-07-21

Status: Closed
Project: MariaDB Server
Component/s: Optimizer - Window functions
Affects Version/s: 10.5.9, 10.2, 10.3, 10.4, 10.5
Fix Version/s: 10.2.40, 10.3.31, 10.4.21, 10.5.12, 10.6.4

Type: Bug Priority: Critical
Reporter: Valerii Kravchuk Assignee: Igor Babaev
Resolution: Fixed Votes: 0
Labels: CTE, crash, window-functions

Issue Links:
Relates
relates to MDEV-13170 Database service (MySQL) stops after ... Closed
relates to MDEV-25766 Unused CTE lead to a crash in find_fi... Closed

 Description   

When the stored procedure that does nothing but passing few parameters to complex SELECT with several CTEs is called for the second time:

MariaDB [(none)]> CALL db.P_NAME4('ALL','ALL','something','20210427','20210428','ALL');
...
4 rows in set (3.102 sec)
 
Query OK, 0 rows affected (3.102 sec)
 
MariaDB [(none)]> CALL db.P_NAME4(NULL,NULL,NULL,NULL,NULL,NULL);
ERROR 2013 (HY000): Lost connection to MySQL server during query

it crashes, with the following stack trace:

 
210429 14:37:00 [ERROR] mysqld got signal 11 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
 
To report this bug, see https://mariadb.com/kb/en/reporting-bugs
 
We will try our best to scrape up some info that will hopefully help
diagnose the problem, but since we have already crashed, 
something is definitely wrong and this may fail.
 
Server version: 10.5.9-6-MariaDB-enterprise-log
key_buffer_size=1073741824
read_buffer_size=2097152
max_used_connections=84
max_threads=65537
thread_count=101
It is possible that mysqld could use up to 
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 940638017 K  bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
 
Thread pointer: 0x7ef374005508
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
stack_bottom = 0x7f069a4dabf8 thread_stack 0x49000
??:0(my_print_stacktrace)[0x55d75f1c8c0e]
??:0(handle_fatal_signal)[0x55d75eba0207]
sigaction.c:0(__restore_rt)[0x7f4725938630]
??:0(find_field_in_tables(THD*, Item_ident*, TABLE_LIST*, TABLE_LIST*, Item**, find_item_error_report_type, bool, bool))[0x55d75e9377c2]
??:0(Item_cond::add_key_fields(JOIN*, KEY_FIELD**, unsigned int*, unsigned long long, SARGABLE_PARAM**))[0x55d75e9c3cc1]
??:0(setup_order(THD*, Bounds_checked_array<Item*>, TABLE_LIST*, List<Item>&, List<Item>&, st_order*, bool))[0x55d75e9d864e]
??:0(setup_windows(THD*, Bounds_checked_array<Item*>, TABLE_LIST*, List<Item>&, List<Item>&, List<Window_spec>&, List<Item_window_func>&))[0x55d75eb067c5]
??:0(JOIN::prepare(TABLE_LIST*, Item*, unsigned int, st_order*, bool, st_order*, Item*, st_order*, st_select_lex*, st_select_lex_unit*))[0x55d75e9e42cf]
??:0(st_select_lex_unit::prepare_join(THD*, st_select_lex*, select_result*, unsigned long long, bool))[0x55d75ea40e3d]
??:0(st_select_lex_unit::prepare(TABLE_LIST*, select_result*, unsigned long long))[0x55d75ea453e6]
??:0(TABLE_LIST::find_derived_handler(THD*))[0x55d75e9584b7]
??:0(mysql_handle_single_derived(LEX*, TABLE_LIST*, unsigned int))[0x55d75e9574f4]
??:0(st_select_lex::handle_derived(LEX*, unsigned int))[0x55d75e9728e7]
??:0(JOIN::prepare(TABLE_LIST*, Item*, unsigned int, st_order*, bool, st_order*, Item*, st_order*, st_select_lex*, st_select_lex_unit*))[0x55d75e9e39e6]
??:0(mysql_select(THD*, TABLE_LIST*, List<Item>&, Item*, unsigned int, st_order*, st_order*, Item*, st_order*, unsigned long long, select_result*, st_select_lex_unit*, st_select_lex*))[0x55d75e9f8c9f]
??:0(handle_select(THD*, LEX*, select_result*, unsigned long))[0x55d75e9f8ff4]
/usr/sbin/mariadbd(+0x634643)[0x55d75e85a643]
??:0(mysql_execute_command(THD*))[0x55d75e99c784]
??:0(sp_instr_stmt::exec_core(THD*, unsigned int*))[0x55d75e8f36c6]
??:0(sp_lex_keeper::reset_lex_and_exec_core(THD*, unsigned int*, bool, sp_instr*))[0x55d75e8fbfca]
??:0(sp_instr_stmt::execute(THD*, unsigned int*))[0x55d75e8fca3c]
??:0(sp_head::execute(THD*, bool))[0x55d75e8f7698]
??:0(sp_head::execute_procedure(THD*, List<Item>*))[0x55d75e8f8c4f]
??:0(comp_ne_creator(bool))[0x55d75e98ee7a]
??:0(Sql_cmd_call::execute(THD*))[0x55d75e992d5a]
??:0(mysql_execute_command(THD*))[0x55d75e99b6a1]
??:0(mysql_parse(THD*, char*, unsigned int, Parser_state*, bool, bool))[0x55d75e99f9ba]
??:0(dispatch_command(enum_server_command, THD*, char*, unsigned int, bool, bool))[0x55d75e9a1af3]
??:0(do_command(THD*))[0x55d75e9a366b]
??:0(tp_callback(TP_connection*))[0x55d75eb22d2f]
??:0(get_event(worker_thread_t*, thread_group_t*, timespec*))[0x55d75ed3dcf0]
??:0(MyCTX_nopad::finish(unsigned char*, unsigned int*))[0x55d75ee15c1d]
pthread_create.c:0(start_thread)[0x7f4725930ea5]
??:0(__clone)[0x7f4723ac98dd]
 
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
Query (0x7efab000f990): WITH GET_INFO AS
	(
		SELECT something <complex query here>
 
        ...
 
        FROM ALL_DATA_final
WHERE ( NAME_CONST('var',NULL) = 'ALL' OR  NAME_CONST('var',NULL) <> 'ALL' AND col1 =  NAME_CONST('var',NULL))



 Comments   
Comment by Alice Sherepa [ 2021-04-29 ]

Repeatable on 10.2-10.5, with sp/ps/ + second execution

CREATE TABLE t1 (a int, b int);
 
prepare stmt from "
with cte1 as (SELECT * FROM (SELECT a,b FROM t1 union SELECT a,0 from t1)dt), 
cte as( 
select cte1.a, 
	sum(cte1.b) over (partition by cte1.a  order by cte1.a),
	sum(cte1.b) over (partition by cte1.a  order by cte1.a) k
from cte1 left join t1 on t1.a = cte1.a)
select * from cte;";
 
execute stmt;
execute stmt;

10.2 b862377c3e9a6818bc2d5

Version: '10.2.38-MariaDB-debug-log' 
210429 14:13:18 [ERROR] mysqld got signal 11 ;
 
sql/signal_handler.cc:221(handle_fatal_signal)[0x55ae759d45ce]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x12730)[0x7ff4ae5cc730]
sql/sql_base.cc:6033(find_field_in_tables(THD*, Item_ident*, TABLE_LIST*, TABLE_LIST*, Item**, find_item_error_report_type, bool, bool))[0x55ae7525747c]
sql/sql_select.cc:22604(find_order_in_list(THD*, Bounds_checked_array<Item*>, TABLE_LIST*, st_order*, List<Item>&, List<Item>&, bool, bool, bool))[0x55ae754ba59e]
sql/sql_select.cc:22724(setup_order(THD*, Bounds_checked_array<Item*>, TABLE_LIST*, List<Item>&, List<Item>&, st_order*, bool))[0x55ae754bb570]
sql/sql_window.cc:211(setup_windows(THD*, Bounds_checked_array<Item*>, TABLE_LIST*, List<Item>&, List<Item>&, List<Window_spec>&, List<Item_window_func>&))[0x55ae7583b482]
sql/sql_select.cc:673(setup_without_group(THD*, Bounds_checked_array<Item*>, TABLE_LIST*, List<TABLE_LIST>&, List<Item>&, List<Item>&, Item**, st_order*, st_order*, List<Window_spec>&, List<Item_window_func>&, bool*, unsigned int*))[0x55ae75413277]
sql/sql_select.cc:812(JOIN::prepare(TABLE_LIST*, unsigned int, Item*, unsigned int, st_order*, bool, st_order*, Item*, st_order*, st_select_lex*, st_select_lex_unit*))[0x55ae75414b6e]
sql/sql_union.cc:596(st_select_lex_unit::prepare(THD*, select_result*, unsigned long))[0x55ae755f90c6]
sql/sql_derived.cc:770(mysql_derived_prepare(THD*, LEX*, TABLE_LIST*))[0x55ae752efb41]
sql/sql_derived.cc:198(mysql_handle_single_derived(LEX*, TABLE_LIST*, unsigned int))[0x55ae752ec631]
sql/table.cc:8124(TABLE_LIST::handle_derived(LEX*, unsigned int))[0x55ae7566f79b]
sql/sql_lex.h:3205(LEX::handle_list_of_derived(TABLE_LIST*, unsigned int))[0x55ae7532b8d0]
sql/sql_lex.cc:3935(st_select_lex::handle_derived(LEX*, unsigned int))[0x55ae7534a4d1]
sql/sql_select.cc:725(JOIN::prepare(TABLE_LIST*, unsigned int, Item*, unsigned int, st_order*, bool, st_order*, Item*, st_order*, st_select_lex*, st_select_lex_unit*))[0x55ae75413960]
sql/sql_select.cc:3827(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*))[0x55ae75433dc5]
sql/sql_select.cc:361(handle_select(THD*, LEX*, select_result*, unsigned long))[0x55ae75410a84]
sql/sql_parse.cc:6274(execute_sqlcom_select(THD*, TABLE_LIST*))[0x55ae75384444]
sql/sql_parse.cc:3585(mysql_execute_command(THD*))[0x55ae7536fbdf]
sql/sql_prepare.cc:5053(Prepared_statement::execute(String*, bool))[0x55ae753df752]
sql/sql_prepare.cc:4482(Prepared_statement::execute_loop(String*, bool, unsigned char*, unsigned char*))[0x55ae753dae92]
sql/sql_prepare.cc:3575(mysql_sql_stmt_execute(THD*))[0x55ae753d5233]
sql/sql_parse.cc:3602(mysql_execute_command(THD*))[0x55ae7536fc24]
sql/sql_parse.cc:7796(mysql_parse(THD*, char*, unsigned int, Parser_state*, bool, bool))[0x55ae7538d78e]
sql/sql_parse.cc:1830(dispatch_command(enum_server_command, THD*, char*, unsigned int, bool, bool))[0x55ae7536470d]
sql/sql_parse.cc:1381(do_command(THD*))[0x55ae75361132]
sql/sql_connect.cc:1336(do_handle_one_connection(CONNECT*))[0x55ae7570af05]
sql/sql_connect.cc:1242(handle_one_connection)[0x55ae7570a7c6]
perfschema/pfs.cc:1871(pfs_spawn_thread)[0x55ae76bab120]
nptl/pthread_create.c:487(start_thread)[0x7ff4ae5c1fa3]
x86_64/clone.S:97(clone)[0x7ff4adf454cf]
 
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
Query (0x62b000000340): with cte1 as (SELECT * FROM (SELECT a,b FROM t1 union SELECT a,0 from t1)dt), 
cte as( 
select cte1.a, 
	sum(cte1.b) over (partition by cte1.a  order by cte1.a),
	sum(cte1.b) over (partition by cte1.a  order by cte1.a) k
from cte1 left join t1 on t1.a = cte1.a)
select * from cte

the same test, but without using cte:

CREATE TABLE t1 (a int);
 
CREATE PROCEDURE sp()
SELECT * FROM (
SELECT dt1.a, sum(dt1.a) over (partition by dt1.a  order by dt1.a), 
              sum(dt1.a) over (partition by dt1.a  order by dt1.a) k
FROM 
(SELECT * FROM (SELECT a FROM t1 UNION SELECT 1)dt2)dt1 
LEFT JOIN t1 on t1.a = dt1.a)dt;
 
call sp();
call sp();

Comment by Igor Babaev [ 2021-06-17 ]

This is a test case using views that causes the same problem:

create table t1 (a int);
insert into t1 values (3), (7), (1), (7), (1), (1), (3), (1), (5);
create table t2 (b int);
insert into t2 values (1), (4), (9), (8), (2), (9), (7), (1);
 
create view v2 as select a from t1 group by a;
create view v1 as select * from v2;
 
create procedure sp1()
select v1.a, 
          sum(v1.a) over (partition by v1.a  order by v1.a) as k,
          avg(v1.a) over (partition by v1.a  order by v1.a)  as m
from v1, t2 where t2.b = v1.a;
 
call sp1();
call sp1();

After the first call of sp1() we have

MariaDB [test]> call sp1();
+------+------+--------+
| a    | k    | m      |
+------+------+--------+
|    1 |    2 | 1.0000 |
|    1 |    2 | 1.0000 |
|    7 |    7 | 7.0000 |
+------+------+--------+

The second call of sp1 causes a crash in the same place of find_field_in_tables() as the reported test case with the procedure sp

Comment by Igor Babaev [ 2021-07-21 ]

A fix for this bug was pushed into 10.2. It should be merged upstream as it is

Generated at Thu Feb 08 09:38:39 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.