Uploaded image for project: 'MariaDB Server'
  1. MariaDB Server
  2. MDEV-19364

Server crashes on certain window function usage

Details

    • Bug
    • Status: Closed (View Workflow)
    • Critical
    • Resolution: Cannot Reproduce
    • 10.3.14, 10.3.16, 10.4.4
    • N/A
    • None
    • C:\Users\lukas> ver
      Microsoft Windows [Version 10.0.17134.706]

      select version();
      version() |
      ------------------------------------|
      10.4.4-MariaDB-1:10.4.4+maria~bionic|

    Description

      I'm running MariaDB in Docker on Windows. Running the following script crashes the server:

      drop table if exists t;
      create table t (i int, j int);
      insert into t values (1, 1), (2, 1), (3, 2), (4, 2);
       
      select 
        i, 
        max(i) over (partition by (select 1))
      from t
      order by i asc;
      

      Attachments

        1. log.txt
          30 kB
        2. my.cnf
          5 kB

        Issue Links

          Activity

            This is easily repeatable with InnoDB table on 10.3.16 (or ColumnStore 1.2.5-1 ):

            openxs@ao756:~$ mcsmysql -uroot test
            Welcome to the MariaDB monitor. Commands end with ; or \g.
            Your MariaDB connection id is 11
            Server version: 10.3.16-MariaDB-log Columnstore 1.2.5-1
             
            Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.
             
            Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
             
            MariaDB [test]> CREATE TABLE `t` ( `id` int(11) NOT NULL AUTO_INCREMENT, `cid` int(11) DEFAULT NULL, `d` datetime DEFAULT NULL, `c` decimal(12,4) DEFAULT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB;
            Query OK, 0 rows affected (0,243 sec)
             
            MariaDB [test]> insert into t(cid, d, c) values (1, '2018-01-01', 20000.05);
            Query OK, 1 row affected (0,056 sec)
             
            MariaDB [test]> insert into t(cid, d, c) select round(rand()*100), date_sub(now(), interval rand()*100 week), round(rand()*100000,2) from t;
            Query OK, 1 row affected (0,051 sec)
            Records: 1 Duplicates: 0 Warnings: 0
             
            MariaDB [test]> insert into t(cid, d, c) select round(rand()*100), date_sub(now(), interval rand()*100 week), round(rand()*100000,2) from t;
            Query OK, 2 rows affected (0,040 sec)
            Records: 2 Duplicates: 0 Warnings: 0
             
            ...
             
            \MariaDB [test]> insert into t(cid, d, c) select round(rand()*100), date_sub(now(), interval rand()*100 week), round(rand()*100000,2) from t;
            Query OK, 32768 rows affected (0,794 sec)
            Records: 32768 Duplicates: 0 Warnings: 0
             
            MariaDB [test]> insert into t(cid, d, c) select round(rand()*100), date_sub(now(), interval rand()*100 week), round(rand()*100000,2) from t;
            Query OK, 65536 rows affected (1,400 sec)
            Records: 65536 Duplicates: 0 Warnings: 0
             
            MariaDB [test]> select count(*) from t;
            +----------+
            | count(*) |
            +----------+
            | 131072 |
            +----------+
            1 row in set (0,070 sec)
             
            MariaDB [test]> select distinct cid, week(d) as week, max(c) over (partition by cid, week(d)) as c_mx, sum(c) over (partition by cid, week(d)) as c_sum, count(c) over (partition by cid, week(d)) as c_cnt, max(week(d)) over (partition by year(d)) as w_max from t where year(d) = '2018';
            ERROR 2013 (HY000): Lost connection to MySQL server during query
            

            In the error log we see:

            190810 13:58:35 [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.3.16-MariaDB-log
            key_buffer_size=536870912
            read_buffer_size=4194304
            max_used_connections=1
            max_threads=153
            thread_count=8
            It is possible that mysqld could use up to
            key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 1781135 K bytes of memory
            Hope that's ok; if not, decrease some variables in the equation.
             
            Thread pointer: 0x7f93740010b8
            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 = 0x7f93c086fe98 thread_stack 0x80000
            /usr/local/mariadb/columnstore/mysql//bin/mysqld(my_print_stacktrace+0x29)[0x563a83082259]
            /usr/local/mariadb/columnstore/mysql//bin/mysqld(handle_fatal_signal+0x307)[0x563a82bcbe57]
            /lib/x86_64-linux-gnu/libpthread.so.0(+0x11390)[0x7f93fb01c390]
            /usr/local/mariadb/columnstore/mysql//bin/mysqld(+0x6997e7)[0x563a82b2e7e7]
            sql/sql_window.cc:436(compare_order_elements)[0x563a82b31d06]
            sql/sql_window.cc:588(compare_window_funcs_by_window_specs)[0x563a82a4c5e2]
            sql/sql_select.cc:3342(JOIN::make_aggr_tables_info())[0x563a82a548f4]
            sql/sql_select.cc:2637(JOIN::optimize_stage2())[0x563a82a5606a]
            sql/sql_select.cc:1533(JOIN::optimize_inner())[0x563a82a5632f]
            sql/sql_select.cc:1455(JOIN::optimize())[0x563a82a5835a]
            sql/sql_select.cc:4514(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*))[0x563a82a58517]
            sql/sql_select.cc:386(handle_select(THD*, LEX*, select_result*, unsigned long))[0x563a82a8d674]
            sql/sql_table.cc:11114(Sql_cmd_create_table_like::execute(THD*))[0x563a82a0243f]
            sql/sql_parse.cc:6064(mysql_execute_command(THD*))[0x563a82a08469]
            sql/sql_parse.cc:7871(mysql_parse(THD*, char*, unsigned int, Parser_state*, bool, bool))[0x563a82a086a2]
            sql/sql_class.h:2885(THD::set_row_count_func(long long))[0x563a82a0a037]
            sql/sql_parse.cc:10666(idb_vtable_process(THD*, unsigned long long, Statement*))[0x563a82a0d139]
            sql/sql_parse.cc:1875(dispatch_command(enum_server_command, THD*, char*, unsigned int, bool, bool))[0x563a82a0e9d0]
            sql/sql_parse.cc:1425(do_command(THD*))[0x563a82ad6054]
            sql/sql_connect.cc:1402(do_handle_one_connection(CONNECT*))[0x563a82ad61d4]
            /lib/x86_64-linux-gnu/libpthread.so.0(+0x76ba)[0x7f93fb0126ba]
            /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7f93fa4a741d]
             
            Trying to get some variables.
            Some pointers may be invalid and cause the dump to abort.
            Query (0x7f93740136a8): is an invalid pointer
            Connection ID (thread ID): 11
            Status: NOT_KILLED
            

            valerii Valerii Kravchuk added a comment - This is easily repeatable with InnoDB table on 10.3.16 (or ColumnStore 1.2.5-1 ): openxs@ao756:~$ mcsmysql -uroot test Welcome to the MariaDB monitor. Commands end with ; or \g. Your MariaDB connection id is 11 Server version: 10.3.16-MariaDB-log Columnstore 1.2.5-1   Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.   Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.   MariaDB [test]> CREATE TABLE `t` ( `id` int(11) NOT NULL AUTO_INCREMENT, `cid` int(11) DEFAULT NULL, `d` datetime DEFAULT NULL, `c` decimal(12,4) DEFAULT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB; Query OK, 0 rows affected (0,243 sec)   MariaDB [test]> insert into t(cid, d, c) values (1, '2018-01-01', 20000.05); Query OK, 1 row affected (0,056 sec)   MariaDB [test]> insert into t(cid, d, c) select round(rand()*100), date_sub(now(), interval rand()*100 week), round(rand()*100000,2) from t; Query OK, 1 row affected (0,051 sec) Records: 1 Duplicates: 0 Warnings: 0   MariaDB [test]> insert into t(cid, d, c) select round(rand()*100), date_sub(now(), interval rand()*100 week), round(rand()*100000,2) from t; Query OK, 2 rows affected (0,040 sec) Records: 2 Duplicates: 0 Warnings: 0   ...   \MariaDB [test]> insert into t(cid, d, c) select round(rand()*100), date_sub(now(), interval rand()*100 week), round(rand()*100000,2) from t; Query OK, 32768 rows affected (0,794 sec) Records: 32768 Duplicates: 0 Warnings: 0   MariaDB [test]> insert into t(cid, d, c) select round(rand()*100), date_sub(now(), interval rand()*100 week), round(rand()*100000,2) from t; Query OK, 65536 rows affected (1,400 sec) Records: 65536 Duplicates: 0 Warnings: 0   MariaDB [test]> select count(*) from t; +----------+ | count(*) | +----------+ | 131072 | +----------+ 1 row in set (0,070 sec)   MariaDB [test]> select distinct cid, week(d) as week, max(c) over (partition by cid, week(d)) as c_mx, sum(c) over (partition by cid, week(d)) as c_sum, count(c) over (partition by cid, week(d)) as c_cnt, max(week(d)) over (partition by year(d)) as w_max from t where year(d) = '2018'; ERROR 2013 (HY000): Lost connection to MySQL server during query In the error log we see: 190810 13:58:35 [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.3.16-MariaDB-log key_buffer_size=536870912 read_buffer_size=4194304 max_used_connections=1 max_threads=153 thread_count=8 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 1781135 K bytes of memory Hope that's ok; if not, decrease some variables in the equation.   Thread pointer: 0x7f93740010b8 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 = 0x7f93c086fe98 thread_stack 0x80000 /usr/local/mariadb/columnstore/mysql//bin/mysqld(my_print_stacktrace+0x29)[0x563a83082259] /usr/local/mariadb/columnstore/mysql//bin/mysqld(handle_fatal_signal+0x307)[0x563a82bcbe57] /lib/x86_64-linux-gnu/libpthread.so.0(+0x11390)[0x7f93fb01c390] /usr/local/mariadb/columnstore/mysql//bin/mysqld(+0x6997e7)[0x563a82b2e7e7] sql/sql_window.cc:436(compare_order_elements)[0x563a82b31d06] sql/sql_window.cc:588(compare_window_funcs_by_window_specs)[0x563a82a4c5e2] sql/sql_select.cc:3342(JOIN::make_aggr_tables_info())[0x563a82a548f4] sql/sql_select.cc:2637(JOIN::optimize_stage2())[0x563a82a5606a] sql/sql_select.cc:1533(JOIN::optimize_inner())[0x563a82a5632f] sql/sql_select.cc:1455(JOIN::optimize())[0x563a82a5835a] sql/sql_select.cc:4514(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*))[0x563a82a58517] sql/sql_select.cc:386(handle_select(THD*, LEX*, select_result*, unsigned long))[0x563a82a8d674] sql/sql_table.cc:11114(Sql_cmd_create_table_like::execute(THD*))[0x563a82a0243f] sql/sql_parse.cc:6064(mysql_execute_command(THD*))[0x563a82a08469] sql/sql_parse.cc:7871(mysql_parse(THD*, char*, unsigned int, Parser_state*, bool, bool))[0x563a82a086a2] sql/sql_class.h:2885(THD::set_row_count_func(long long))[0x563a82a0a037] sql/sql_parse.cc:10666(idb_vtable_process(THD*, unsigned long long, Statement*))[0x563a82a0d139] sql/sql_parse.cc:1875(dispatch_command(enum_server_command, THD*, char*, unsigned int, bool, bool))[0x563a82a0e9d0] sql/sql_parse.cc:1425(do_command(THD*))[0x563a82ad6054] sql/sql_connect.cc:1402(do_handle_one_connection(CONNECT*))[0x563a82ad61d4] /lib/x86_64-linux-gnu/libpthread.so.0(+0x76ba)[0x7f93fb0126ba] /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7f93fa4a741d]   Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7f93740136a8): is an invalid pointer Connection ID (thread ID): 11 Status: NOT_KILLED

            valerii I cannot reproduce it on 10.3.16

            MariaDB [test]> select count(*) from t;
            +----------+
            | count(*) |
            +----------+
            |   131072 |
            +----------+
            1 row in set (1.751 sec)
             
            MariaDB [test]> explain
                -> select distinct cid, week(d) as week, max(c) over (partition by cid, week(d)) as c_mx, sum(c) over (partition by cid, week(d)) as c_sum, count(c) over (partition by cid, week(d)) as c_cnt, max(week(d)) over (partition by year(d)) as w_max from t where year(d) = '2018';
            +------+-------------+-------+------+---------------+------+---------+------+--------+------------------------------+
            | id   | select_type | table | type | possible_keys | key  | key_len | ref  | rows   | Extra                        |
            +------+-------------+-------+------+---------------+------+---------+------+--------+------------------------------+
            |    1 | SIMPLE      | t     | ALL  | NULL          | NULL | NULL    | NULL | 131540 | Using where; Using temporary |
            +------+-------------+-------+------+---------------+------+---------+------+--------+------------------------------+
            1 row in set (0.004 sec)
            
            

            varun Varun Gupta (Inactive) added a comment - valerii I cannot reproduce it on 10.3.16 MariaDB [test]> select count(*) from t; +----------+ | count(*) | +----------+ | 131072 | +----------+ 1 row in set (1.751 sec)   MariaDB [test]> explain -> select distinct cid, week(d) as week, max(c) over (partition by cid, week(d)) as c_mx, sum(c) over (partition by cid, week(d)) as c_sum, count(c) over (partition by cid, week(d)) as c_cnt, max(week(d)) over (partition by year(d)) as w_max from t where year(d) = '2018'; +------+-------------+-------+------+---------------+------+---------+------+--------+------------------------------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | +------+-------------+-------+------+---------------+------+---------+------+--------+------------------------------+ | 1 | SIMPLE | t | ALL | NULL | NULL | NULL | NULL | 131540 | Using where; Using temporary | +------+-------------+-------+------+---------------+------+---------+------+--------+------------------------------+ 1 row in set (0.004 sec)
            David.Hall David Hall (Inactive) added a comment - - edited

            I can easily reproduce it for InnoDB table on Columnstore 1.2.5 using MariaDB 10.3.16. However, it doesn't break on vanilla MariaDB 10.3.16. Bummer.

            This breaks:

            select avg(comm_total) over (partition by customer) as wk_comm_avg, max(week(trade_date)) over (partition by year(trade_date)) as max_week from book_entry_cs;
            

            this does not break:
            (remove the partition from first or function from partition of second)

            select avg(comm_total) over () as wk_comm_avg, max(week(trade_date)) over (partition by year(trade_date)) as max_week from book_entry_cs;
            --or--
            select avg(comm_total) over (partition by customer) as wk_comm_avg, max(week(trade_date)) over (partition by trade_date) as max_week from book_entry_cs;
            

            David.Hall David Hall (Inactive) added a comment - - edited I can easily reproduce it for InnoDB table on Columnstore 1.2.5 using MariaDB 10.3.16. However, it doesn't break on vanilla MariaDB 10.3.16. Bummer. This breaks: select avg(comm_total) over (partition by customer) as wk_comm_avg, max(week(trade_date)) over (partition by year(trade_date)) as max_week from book_entry_cs; this does not break: (remove the partition from first or function from partition of second) select avg(comm_total) over () as wk_comm_avg, max(week(trade_date)) over (partition by year(trade_date)) as max_week from book_entry_cs; --or-- select avg(comm_total) over (partition by customer) as wk_comm_avg, max(week(trade_date)) over (partition by trade_date) as max_week from book_entry_cs;
            David.Hall David Hall (Inactive) added a comment - - edited

            In debug mode, it asserts the following in compare_order_elements():
            DBUG_ASSERT(item1->type() == Item::FIELD_ITEM &&
            item2->type() == Item::FIELD_ITEM);

            In actuality, item2->type() == item::FUNC_ITEM

            Not sure how this gets this way.

            David.Hall David Hall (Inactive) added a comment - - edited In debug mode, it asserts the following in compare_order_elements(): DBUG_ASSERT(item1->type() == Item::FIELD_ITEM && item2->type() == Item::FIELD_ITEM); In actuality, item2->type() == item::FUNC_ITEM Not sure how this gets this way.

            In sql_select.cc optimize_stage2(), Columnstore has added:

              // @InfiniDB We don't need tmp table for vtable create phase. Plus
              // to build tmp table may corrupt some field table_name & db_name (for some reason)
              if (thd->infinidb_vtable.vtable_state == THD::INFINIDB_CREATE_VTABLE)
            	need_tmp = false;
            

            Removing this allows the query to run against InnoDB correcty. Investigating other things.

            As far as I can tell, this is a Columnstore build only problem. MCOL-3434 has been opened to track it.

            David.Hall David Hall (Inactive) added a comment - In sql_select.cc optimize_stage2(), Columnstore has added: // @InfiniDB We don't need tmp table for vtable create phase. Plus // to build tmp table may corrupt some field table_name & db_name (for some reason) if (thd->infinidb_vtable.vtable_state == THD::INFINIDB_CREATE_VTABLE) need_tmp = false; Removing this allows the query to run against InnoDB correcty. Investigating other things. As far as I can tell, this is a Columnstore build only problem. MCOL-3434 has been opened to track it.

            People

              varun Varun Gupta (Inactive)
              lukas.eder Lukas Eder
              Votes:
              0 Vote for this issue
              Watchers:
              8 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:

                Git Integration

                  Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.