[MDEV-19456] Server crashes using ROW_NUMBER() in query Created: 2019-05-13  Updated: 2019-05-13  Resolved: 2019-05-13

Status: Closed
Project: MariaDB Server
Component/s: Data Manipulation - Subquery
Affects Version/s: 10.3.14
Fix Version/s: N/A

Type: Bug Priority: Major
Reporter: Johannes Finker Assignee: Alice Sherepa
Resolution: Duplicate Votes: 0
Labels: None
Environment:

CentOS 7


Issue Links:
Duplicate
is duplicated by MDEV-15837 Assertion `item1->type() == Item::FIE... Closed

 Description   

After upgrading to 10.3 one of our queries crashes the DB. The original query is quite a bit longer, but I was able to reduce it to a reproducible minimum. I know, that the following statement does not make a lot of sense, but it still should not crash the server.

Create TABLE tmp1 (
	id INT(10) UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY,
	t DATETIME,
	other_id INT(10) UNSIGNED,
    d VARCHAR(100) NOT NULL
);
select * from tmp1;
select id, 
row_number() over (partition by other_id order by isnull(t2) ASC) as order1,
row_number() over (order by isnull(t2) ASC) as order2
FROM 
(SELECT 1 AS Type, id, other_id, ifnull(t, 0) as t2, d FROM tmp1) aaa;

log file from Server:

Server version: 10.3.14-MariaDB-log
key_buffer_size=134217728
read_buffer_size=131072
max_used_connections=7
max_threads=252
thread_count=27
It is possible that mysqld could use up to 
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 685022 K  bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
 
Thread pointer: 0x7f2c140013a8
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 = 0x7f2b3020fd30 thread_stack 0x49000
/usr/sbin/mysqld(my_print_stacktrace+0x2e)[0x56450da94dfe]
/usr/sbin/mysqld(handle_fatal_signal+0x357)[0x56450d534cc7]
sigaction.c:0(__restore_rt)[0x7f2c8081d5d0]
/usr/sbin/mysqld(+0x6dde0b)[0x56450d48fe0b]
/usr/sbin/mysqld(+0x6ddf7b)[0x56450d48ff7b]
/usr/sbin/mysqld(_ZN24Window_funcs_computation5setupEP3THDP4ListI16Item_window_funcEP13st_join_table+0x1b2)[0x56450d494382]
/usr/sbin/mysqld(_ZN4JOIN21make_aggr_tables_infoEv+0x1640)[0x56450d3a78e0]
/usr/sbin/mysqld(_ZN4JOIN15optimize_stage2Ev+0x1502)[0x56450d3b0ae2]
/usr/sbin/mysqld(_ZN4JOIN14optimize_innerEv+0xaef)[0x56450d3b298f]
/usr/sbin/mysqld(_ZN4JOIN8optimizeEv+0x37)[0x56450d3b2c27]
/usr/sbin/mysqld(_Z12mysql_selectP3THDP10TABLE_LISTjR4ListI4ItemEPS4_jP8st_orderS9_S7_S9_yP13select_resultP18st_select_lex_unitP13st_select_lex+0x94)[0x56450d3b4394]
/usr/sbin/mysqld(_Z13handle_selectP3THDP3LEXP13select_resultm+0x1cc)[0x56450d3b4f2c]
/usr/sbin/mysqld(+0x4b543c)[0x56450d26743c]
/usr/sbin/mysqld(_Z21mysql_execute_commandP3THD+0x239b)[0x56450d357edb]
/usr/sbin/mysqld(_Z11mysql_parseP3THDPcjP12Parser_statebb+0x22b)[0x56450d35ecab]
/usr/sbin/mysqld(+0x5ad639)[0x56450d35f639]
/usr/sbin/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcjbb+0x1299)[0x56450d360f89]
/usr/sbin/mysqld(_Z10do_commandP3THD+0x13e)[0x56450d36288e]
/usr/sbin/mysqld(_Z24do_handle_one_connectionP7CONNECT+0x1aa)[0x56450d438b6a]
/usr/sbin/mysqld(handle_one_connection+0x3d)[0x56450d438c8d]
pthread_create.c:0(start_thread)[0x7f2c80815dd5]
/lib64/libc.so.6(clone+0x6d)[0x7f2c7ebb7ead]
 
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
Query (0x7f2c14012040): select id,  row_number() over (partition by other_id order by isnull(t2) ASC) as order1, row_number() over (order by isnull(t2) ASC) as order2 FROM  (SELECT 1 AS Type, id, other_id, i
fnull(t, 0) as t2, d FROM tmp1) aaa
Connection ID (thread ID): 87



 Comments   
Comment by Alice Sherepa [ 2019-05-13 ]

Thanks a lot for the report. This is the same issue as MDEV-15837, fixed in 10.3.15.

Generated at Thu Feb 08 08:51:50 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.