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

MariaDB crash in JOIN optimization

    XMLWordPrintable

Details

    • Bug
    • Status: Closed (View Workflow)
    • Major
    • Resolution: Duplicate
    • 11.3
    • N/A
    • Server
    • Ubuntu Desktop 20.04 LTS
      Intel(R) Core(TM) i7-10700 CPU @ 2.90GHz

    Description

      The latest version of MariDB Server: Git commit hash: (905c3d61e18a) crashes when executing the following query:

      DROP DATABASE IF exists test1;
      CREATE DATABASE test1;
      USE test1;
      CREATE TABLE v0 ( v1 INT , v2 INT ) ;
      CREATE VIEW v3 AS SELECT * FROM v0 WHERE v1 = 128 ORDER BY v1 ;
      INSERT INTO v3 ( v2 ) SELECT v2 FROM v3 WHERE v1 LIKE NULL ;

      Here is the crashing stack trace from version 905c3d61e18a:

      #0 make_join_statistics (keyuse_array=0xfffef006a9e8, tables_list=..., join=0xfffef006a688) at /home/mysql/mariadb/sql/sql_select.cc:5905
      #1 JOIN::optimize_inner (this=0xfffef006a688) at /home/mysql/mariadb/sql/sql_select.cc:2624
      #2 0x0000aaaab3c76964 in JOIN::optimize (this=0xfffef006a688) at /home/mysql/mariadb/sql/sql_select.cc:1944
      #3 0x0000aaaab3c76a54 in mysql_select (thd=0xfffef0000c68, tables=0xfffef00132f8, fields=..., conds=0xfffef0013c40, og_num=1, order=0xfffef0015ce0, group=0x0,
      having=0x0, proc_param=0x0, select_options=<optimized out>, result=0xfffef006a5c8, unit=0xfffef0004fe0, select_lex=0xfffef0012cd0)
      at /home/mysql/mariadb/sql/sql_select.cc:5235
      #4 0x0000aaaab3c770c8 in handle_select (thd=0xfffef0000c68, lex=0xfffef0004f00, result=0xfffef006a5c8, setup_tables_done_option=<optimized out>)
      at /home/mysql/mariadb/sql/sql_select.cc:628
      #5 0x0000aaaab3c165ac in mysql_execute_command (thd=0xfffef0000c68, is_called_from_prepared_stmt=<optimized out>) at /home/mysql/mariadb/sql/sql_parse.cc:4575
      #6 0x0000aaaab3c05a68 in mysql_parse (thd=0xfffef0000c68, rawbuf=<optimized out>, length=<optimized out>, parser_state=<optimized out>)
      at /home/mysql/mariadb/sql/sql_parse.cc:7744
      #7 0x0000aaaab3c0fb5c in dispatch_command (command=COM_QUERY, thd=0xfffef0000c68, packet=0xfffef00087d9 "INSERT INTO v3 ( v2 ) SELECT v2 FROM v3 WHERE v1 LIKE NULL",
      packet_length=<optimized out>, blocking=true) at /home/mysql/mariadb/sql/sql_class.h:1532
      #8 0x0000aaaab3c117b8 in do_command (thd=0xfffef0000c68, blocking=true) at /home/mysql/mariadb/sql/sql_parse.cc:1406
      #9 0x0000aaaab3d0a14c in do_handle_one_connection (connect=<optimized out>, put_in_cache=true) at /home/mysql/mariadb/sql/sql_connect.cc:1445
      #10 0x0000aaaab3d0a528 in handle_one_connection (arg=0xaaaab75f44d8) at /home/mysql/mariadb/sql/sql_connect.cc:1347
      #11 0x0000aaaab4021788 in pfs_spawn_thread (arg=<optimized out>) at /home/mysql/mariadb/storage/perfschema/pfs.cc:2201
      #12 0x0000ffff81240624 in start_thread (arg=0xaaaab40216e8 <pfs_spawn_thread(void*)>) at pthread_create.c:477
      #13 0x0000ffff80ecf49c in thread_start () at ../sysdeps/unix/sysv/linux/aarch64/clone.S:78

      Some other useful information:

      Optimizer switch: index_merge=on,index_merge_union=on,index_merge_sort_union=on,index_merge_intersection=on,index_merge_sort_intersection=off,engine_condition_pushdown=off,index_condition_pushdown=on,derived_merge=on,derived_with_keys=on,firstmatch=on,loosescan=on,materialization=on,in_to_exists=on,semijoin=on,partial_match_rowid_merge=on,partial_match_table_scan=on,subquery_cache=on,mrr=off,mrr_cost_based=off,mrr_sort_keys=off,outer_join_with_cache=on,semijoin_with_cache=on,join_cache_incremental=on,join_cache_hashed=on,join_cache_bka=on,optimize_join_buffer_size=on,table_elimination=on,extended_keys=on,exists_to_in=on,orderby_uses_equalities=on,condition_pushdown_for_derived=on,split_materialized=on,condition_pushdown_for_subquery=on,rowid_filter=on,condition_pushdown_from_having=on,not_null_range_scan=off,hash_join_cardinality=on,sargable_casefold=on

      The bug is similar to MDEV-28501 as the original PoC triggered the same stack trace as in MDEV-28501, but the stack trace changes after query simplification. However, the PoC from MDEV-28501 couldn't trigger the crash right now, but the PoC provided from this report could. Therefore, I suspect there might be a different root cause between these two reports.

      Attachments

        Issue Links

          Activity

            People

              Unassigned Unassigned
              luy70 Yu Liang
              Votes:
              0 Vote for this issue
              Watchers:
              2 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.