Details
-
Bug
-
Status: Closed (View Workflow)
-
Critical
-
Resolution: Fixed
-
10.5.2, 10.2(EOL), 10.3(EOL), 10.4(EOL), 10.5
-
None
-
Ubuntu 18.04
Description
We found an assertion fail that crashes the latest version of mariadb.
POC:
—
CREATE TEMPORARY TABLE v0 ( v1 NUMERIC PRIMARY KEY ) ; |
SELECT v1 FROM v0 WHERE v1 < 8 GROUP BY 26631087.000000 WINDOW v2 AS ( PARTITION BY v1 ORDER BY 'x' DESC ) ; |
—
Stack dump:
|
|
```
|
Server version: 10.5.3-MariaDB-debug
|
key_buffer_size=134217728
|
read_buffer_size=131072
|
max_used_connections=1
|
max_threads=153
|
thread_count=2
|
It is possible that mysqld could use up to
|
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 467925 K bytes of memory
|
Hope that's ok; if not, decrease some variables in the equation.
|
|
|
Thread pointer: 0x7f0208000d78
|
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 = 0x7f0274877dc0 thread_stack 0x49000
|
fil/fil0fil.cc:3410(fil_ibd_discover(unsigned long, Datafile&))[0x32d4681]
|
sql/multi_range_read.cc:764(Mrr_ordered_index_reader::refill_buffer(bool))[0x13c0898]
|
??:0(__restore_rt)[0x7f027ac16890]
|
linux/raise.c:51(__GI_raise)[0x7f02788c8e97]
|
stdlib/abort.c:81(__GI_abort)[0x7f02788ca801]
|
assert/assert.c:89(__assert_fail_base)[0x7f02788ba39a]
|
??:0(__assert_fail)[0x7f02788ba412]
|
sql/sql_alloc.h:40(sp_instr_hpush_jump::~sp_instr_hpush_jump())[0xb55f7b]
|
sql/log_event.h:1461(queue_event(Master_info*, char const*, unsigned long))[0xb09548]
|
sql/log_event.h:2752(rpl_master_has_bug(Relay_log_info const*, unsigned int, bool, bool (*)(void const*), void const*))[0xb14a50]
|
sql/sql_alloc.h:39(show_master_info_get_fields(THD*, List<Item>*, bool, unsigned long))[0xae4b43]
|
sql/sql_list.h:195(show_master_info_get_fields(THD*, List<Item>*, bool, unsigned long))[0xae2fa2]
|
sql/mysqld.cc:3213(my_message_sql)[0xa3bb5e]
|
sql/sql_basic_types.h:151(time_round_mode_t::time_round_mode_t(unsigned long long))[0xa2c499]
|
sql/sys_vars.ic:627(Sys_var_charptr_fscs::Sys_var_charptr(char const*, char const, int, long, unsigned long, CMD_LINE, char const, PolyLock*, sys_var::binlog_status_enum, bool (*)(PolyLock**, THD*, set_v$
|
r*), bool (*)(sys_var::binlog_status_enum, THD, enum_var_type), char const))[0xa07b70]
|
sql/sys_vars.ic:324(Sys_var_typelib::Sys_var_typelib(char const*, char const*, int, long, CMD_LINE, enum_mysql_show_type, char const**, unsigned long long, PolyLock*, sys_var::binlog_status_enum, bool (*$
|
(sys_var*, THD*, set_var*), bool (*)(sys_var*, THD*, enum_var_type), char const*))[0x9fb5cc]
|
sql/sys_vars.cc:5730(__cxx_global_var_init.1236)[0xa099cb]
|
sql/item.h:4563(Item_empty_string::Item_empty_string(THD*, char const*, unsigned int, charset_info_st const*))[0xedb6d1]
|
sql/item.h:746(show_binlog_info_get_fields(THD*, List<Item>*))[0xedaec1]
|
gcalc_slicescan.cc:0(__afl_fork_wait_loop)[0x1e8dfc6]
|
nptl/pthread_create.c:463(start_thread)[0x7f027ac0b6db]
|
x86_64/clone.S:97(clone)[0x7f02789ab88f]
|
|
|
Trying to get some variables.
|
Some pointers may be invalid and cause the dump to abort.
|
Query (0x7f02080127d0): SELECT v1 FROM v0 WHERE v1 < 8 GROUP BY 26631087.000000 WINDOW v2 AS ( PARTITION BY v1 ORDER BY 'x' DESC )
|
Connection ID (thread ID): 3
|
Status: NOT_KILLED
|
```
|
Attachments
Issue Links
- relates to
-
-
- Closed
-
Activity
alice I expect named window specs to work, I have seen few tests about it in the test suite.
The test case that has been reported is not how window named specs should be used, there should be a window function * too*, an example would be:
MariaDB [test]> select a, row_number() over w2 from t1 window w2 as (partition by a);
|
+------+----------------------+
|
| a | row_number() over w2 |
|
+------+----------------------+
|
| 1 | 1 |
|
| 2 | 1 |
|
| 3 | 1 |
|
+------+----------------------+
|
3 rows in set (0.00 sec)
|
|
Attached a one line fix for this issue. This fixes the test case here.
Will try to get Named Window specs to the documentation
Review input provided over email.
Ok to push once it is addressed.
Thanks! I repeated on 10.2-10.5.
#3 <signal handler called>#4 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50#5 0x00007fd2d8b19535 in __GI_abort () at abort.c:79#6 0x00007fd2d8b1940f in __assert_fail_base (fmt=0x7fd2d8c7bee0 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=0x56404950deb8 "((select_options & (1ULL << 17)) ? 1 : 0)", file=0x56404950d988 "/10.2/sql/sql_select.cc", line=2787, function=<optimized out>) at assert.c:92#7 0x00007fd2d8b27102 in __GI___assert_fail (assertion=0x56404950deb8 "((select_options & (1ULL << 17)) ? 1 : 0)", file=0x56404950d988 "/10.2/sql/sql_select.cc", line=2787, function=0x564049510460 <JOIN::make_aggr_tables_info()::__PRETTY_FUNCTION__> "bool JOIN::make_aggr_tables_info()") at assert.c:101#8 0x0000564048a8de69 in JOIN::make_aggr_tables_info (this=0x7fd2b8013338) at /10.2/sql/sql_select.cc:2787#9 0x0000564048a8bdb1 in JOIN::optimize_inner (this=0x7fd2b8013338) at /10.2/sql/sql_select.cc:2241#10 0x0000564048a87e9f in JOIN::optimize (this=0x7fd2b8013338) at /10.2/sql/sql_select.cc:1113#11 0x0000564048a9137e in mysql_select (thd=0x7fd2b8000d50, tables=0x7fd2b80128f0, wild_num=0, fields=..., conds=0x0, og_num=1, order=0x0, group=0x7fd2b8013000, having=0x0, proc_param=0x0, select_options=2147748608, result=0x7fd2b8013318, unit=0x7fd2b8004948, select_lex=0x7fd2b8005088) at /10.2/sql/sql_select.cc:3814#12 0x0000564048a85654 in handle_select (thd=0x7fd2b8000d50, lex=0x7fd2b8004888, result=0x7fd2b8013318, setup_tables_done_option=0) at /10.2/sql/sql_select.cc:361#13 0x0000564048a51468 in execute_sqlcom_select (thd=0x7fd2b8000d50, all_tables=0x7fd2b80128f0) at /10.2/sql/sql_parse.cc:6225#14 0x0000564048a47d60 in mysql_execute_command (thd=0x7fd2b8000d50) at /10.2/sql/sql_parse.cc:3532#15 0x0000564048a55195 in mysql_parse (thd=0x7fd2b8000d50, rawbuf=0x7fd2b80126a8 "select a from t1 group by 2.000000 window w2 as (partition by a)", length=64, parser_state=0x7fd2cec7a5f0, is_com_multi=false, is_next_command=false) at /10.2/sql/sql_parse.cc:7740#16 0x0000564048a435d6 in dispatch_command (command=COM_QUERY, thd=0x7fd2b8000d50, packet=0x7fd2b8008b01 "select a from t1 group by 2.000000 window w2 as (partition by a)", packet_length=64, is_com_multi=false, is_next_command=false) at /10.2/sql/sql_parse.cc:1831#17 0x0000564048a4205b in do_command (thd=0x7fd2b8000d50) at /10.2/sql/sql_parse.cc:1385#18 0x0000564048b958ae in do_handle_one_connection (connect=0x56404c4a57b0) at /10.2/sql/sql_connect.cc:1336#19 0x0000564048b95619 in handle_one_connection (arg=0x56404c4a57b0) at /10.2/sql/sql_connect.cc:1241#20 0x000056404939529c in pfs_spawn_thread (arg=0x56404c55ec40) at /10.2/storage/perfschema/pfs.cc:1869#21 0x00007fd2d926cfa3 in start_thread (arg=<optimized out>) at pthread_create.c:486#22 0x00007fd2d8bf04cf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95(Named window frames are not documented in KB (
MDEV-17191) -should they work in MariaDB at all?)